Workload Scheduler for z/OS Versión 8.6 Personalización y ajuste SC32-1265-06 Workload Scheduler for z/OS Versión 8.6 Personalización y ajuste SC32-1265-06 Nota Antes de utilizar esta información y el producto al que da soporte, lea la información incluida en el apartado “Avisos” en la página 437. Esta publicación es la traducción del original inglés IBM Tivoli Workload Scheduler for z/OS: Customization and Tuning (SC32-1265-04). Esta edición corresponde a la versión 8, release 6 de IBM Tivoli Workload Scheduler for z/OS (número de programa 5698-A17) y a todos los releases y modificaciones posteriores hasta que se indique lo contrario en nuevas ediciones. Esta edición sustituye a la edición inglesa SC32-1265-05. © Copyright IBM Corporation 1991, 2011. Contenido Figuras . . . . . . . . . . . . . . . ix Tablas . . . . . . . . . . . . . . . xi Acerca de esta publicación . . . . . xiii Novedades de este release . . . . . . . . . xiii Novedades de esta publicación . . . . . . . xiii A quién va dirigida esta publicación . . . . . . xiv Publicaciones . . . . . . . . . . . . . xiv Utilización de LookAt para consultar la explicación de los mensajes . . . . . . . . . . . . . xiv Accesibilidad . . . . . . . . . . . . . . xv Formación técnica de Tivoli . . . . . . . . . xv Información sobre soporte . . . . . . . . . xv Convenios utilizados en esta publicación . . . . xvi Cómo leer los diagramas de sintaxis . . . . . . xvi Parte 1. Personalización de IBM Tivoli Workload Scheduler for z/OS . 1 Capítulo 1. Definición de sentencias de inicialización. . . . . . . . . . . . . 5 | Especificación de la sentencia . . . . . . . . . 5 Creación de la sentencia . . . . . . . . . 5 Almacenamiento de sentencias . . . . . . . 6 Alteración temporal de sentencias EQQPARM . . 6 Selección de las sentencias adecuadas . . . . . 6 ALERTS . . . . . . . . . . . . . . . 10 AROPTS . . . . . . . . . . . . . . . 15 AUDIT . . . . . . . . . . . . . . . . 18 AUDITCP . . . . . . . . . . . . . . . 21 AUTHDEF . . . . . . . . . . . . . . 22 BATCHOPT . . . . . . . . . . . . . . 26 CPUREC . . . . . . . . . . . . . . . 38 DBCSOPTS . . . . . . . . . . . . . . 39 DBOPT . . . . . . . . . . . . . . . . 41 DOMREC . . . . . . . . . . . . . . . 44 DSTOPTS . . . . . . . . . . . . . . . 45 DSTUTIL . . . . . . . . . . . . . . . 51 ERDROPTS . . . . . . . . . . . . . . 54 EWTROPTS . . . . . . . . . . . . . . 56 EXITS . . . . . . . . . . . . . . . . 62 FLOPTS . . . . . . . . . . . . . . . 64 HTTPOPTS . . . . . . . . . . . . . . 68 INCLUDE . . . . . . . . . . . . . . . 73 INIT . . . . . . . . . . . . . . . . . 74 INTFOPTS. . . . . . . . . . . . . . . 79 JCCOPTS . . . . . . . . . . . . . . . 81 JTOPTS . . . . . . . . . . . . . . . . 85 MONOPTS . . . . . . . . . . . . . . 111 MONPOL . . . . . . . . . . . . . . 113 NOERROR . . . . . . . . . . . . . . 115 OPCOPTS . . . . . . . . . . . . . . 120 RCLDDP . . . . . . . . . . . . . . . 135 © Copyright IBM Corp. 1991, 2011 RCLDSNP . RCLOPTS . RCLSKIP . . RESOPTS. . RESOURCE . RODMOPTS. ROUTOPTS . SERVOPTS . TCPOPTS . TOPOLOGY . TRGOPT . . TRROPTS . USRREC . . XCFOPTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 137 144 146 151 152 156 161 166 171 172 174 176 177 Capítulo 2. Identificación de sentencias-parámetros de inicialización relacionados. . . . . . 179 Configuración . . . . . . . . . . . . Seguridad . . . . . . . . . . . . . Generación de información de auditoría (datos de registro JT) . . . . . . . . . . . . . Determinación del éxito o fracaso de un trabajo Recuperación . . . . . . . . . . . . Reinicio y limpieza . . . . . . . . . Recuperación de registros de trabajo. . . . Recuperación automática de trabajos . . . Reinicio de la carga de trabajo. . . . . . Rendimiento. . . . . . . . . . . . . Generación de informes . . . . . . . . . Supervisión de RODM . . . . . . . . . Proceso de salida . . . . . . . . . . . Planificación global con capacidades de tolerancia a errores . . . . . . . . . . . . . . Configuración de red . . . . . . . . . Definiciones de trabajo . . . . . . . . Ajustes regionales . . . . . . . . . . Integración de WLM . . . . . . . . . . Supervisión externa . . . . . . . . . . . 180 . 181 . 182 182 . 183 . 184 . 185 . 185 . 186 . 186 . 187 . 188 . 188 . . . . . . 189 189 191 191 192 193 Capítulo 3. Implementación de seguridad . . . . . . . . . . . . . 195 Planificación de la implementación de seguridad Cómo Tivoli Workload Scheduler for z/OS verifica la autorización de acceso . . . . . . Identificación de usuarios . . . . . . . . Establecimiento de convenios de denominación para recursos de IBM Tivoli Workload Scheduler for z/OS . . . . . . . . . . . . . . Agrupación de usuarios y recursos de RACF Consideraciones generales de seguridad . . . Control del acceso a Tivoli Workload Scheduler for z/OS . . . . . . . . . . . . . . . . Control del acceso al subsistema Tivoli Workload Scheduler for z/OS . . . . . . . 195 196 197 198 198 199 200 200 iii Control del acceso a recursos fijos de Tivoli Workload Scheduler for z/OS . . . . . . . Control del acceso a subrecursos de Tivoli Workload Scheduler for z/OS . . . . . . . Control del acceso a Tivoli Workload Scheduler for z/OS desde APPC . . . . . . . . . Control del acceso a Tivoli Workload Scheduler for z/OS utilizando Dynamic Workload Console Control del acceso mediante mandatos TSO . . Funciones y datos que puede proteger . . . . . Requisitos de acceso a recursos fijos para usuarios de diálogos . . . . . . . . . . . . . . Ejemplos de estrategias de seguridad . . . . . Estrategia de seguridad centralizada. . . . . Estrategia de seguridad descentralizada . . . 201 201 203 205 209 210 215 219 219 221 Capítulo 4. Salidas de Tivoli Workload Scheduler for z/OS . . . . . . . . . 225 Invocación de las salidas de usuario de Tivoli Workload Scheduler for z/OS . . . . . . . . Salida de inicio/detención (EQQUX000) . . . Salida de envío de trabajo (EQQUX001) . . . Salida de lectura de biblioteca de trabajos (EQQUX002) . . . . . . . . . . . . Salida de información de descripción de la aplicación (EQQUX003) . . . . . . . . . Salida de filtrado de sucesos (EQQUX004). . . Salida de archivado de SYSOUT (EQQUX005) Salida de creación de registro de incidencia (EQQUX006) . . . . . . . . . . . . Salida de cambio de estado de la operación (EQQUX007) . . . . . . . . . . . . Salida de iniciación de la operación (EQQUX009) . . . . . . . . . . . . Salida de grabación de registro de seguimiento de trabajos (EQQUX011) . . . . . . . . . Salida de prevención de adaptación de trabajos (EQQUX013) . . . . . . . . . . . . Salida de operación dependiente del tiempo (EQQUX014) . . . . . . . . . . . . Salida de incorporación de JCL (en directiva FETCH) . . . . . . . . . . . . . . Salida de sustitución de variables (en la variable de definición de trabajos o JCL) . . . . . . Salida de recuperación automática de trabajos (en la sentencia RECOVER). . . . . . . . Salida de informe de planificación diaria (EQQDPUE1) . . . . . . . . . . . . Salida de catálogo EQQDELDS/EQQCLEAN (EQQUXCAT) . . . . . . . . . . . . Salida de resolución de GDG de EQQCLEAN (EQQUXGDG) . . . . . . . . . . . . Validación de descripción de la aplicación (EQQUXPIF) . . . . . . . . . . . . Salida de entorno de planificación diaria EQQDPX01 . . . . . . . . . . . . . Salida de inicio/detención de Tivoli Workload Scheduler for z/OS (EQQUX000) . . . . . . . Instalación de la salida . . . . . . . . . Interfaz a la salida. . . . . . . . . . . Salida de envío de trabajo (EQQUX001) . . . . iv 227 227 227 227 227 227 227 228 228 228 228 228 228 228 229 229 229 229 229 229 229 231 231 231 232 Instalación de la salida . . . . . . . . . Interfaz a la salida. . . . . . . . . . . Salida de lectura de biblioteca de trabajos (EQQUX002) . . . . . . . . . . . . . Instalación de la salida . . . . . . . . . Interfaz a la salida. . . . . . . . . . . Salida de información de descripción de la aplicación (EQQUX003) . . . . . . . . . . Instalación de la salida . . . . . . . . . Interfaz a la salida. . . . . . . . . . . Salida de filtrado de sucesos (EQQUX004). . . . Instalación de la salida . . . . . . . . . Interfaz a la salida. . . . . . . . . . . Salida de archivado de SYSOUT (EQQUX005) . . Instalación de la salida . . . . . . . . . Interfaz a la salida. . . . . . . . . . . Salida de creación de registro de incidencia (EQQUX006) . . . . . . . . . . . . . Instalación de la salida . . . . . . . . . Interfaz a la salida. . . . . . . . . . . Salida de cambio de estado de la operación (EQQUX007) . . . . . . . . . . . . . Instalación de la salida . . . . . . . . . Interfaz a la salida. . . . . . . . . . . Salida de iniciación de la operación (EQQUX009) Instalación de la salida . . . . . . . . . Interfaz a la salida. . . . . . . . . . . Salida de grabación de registro de seguimiento de trabajos (EQQUX011) . . . . . . . . . . . Instalación de la salida . . . . . . . . . Interfaz a la salida. . . . . . . . . . . Salida de suceso de adaptación de trabajos (EQQUX013) . . . . . . . . . . . . . Instalación de la salida . . . . . . . . . Interfaz a la salida. . . . . . . . . . . Salida de operación dependiente del tiempo (EQQUX014) . . . . . . . . . . . . . Instalación de la salida . . . . . . . . . Interfaz a la salida. . . . . . . . . . . Salida de catálogo EQQDELDS/EQQCLEAN (EQQUXCAT) . . . . . . . . . . . . . Instalación de la salida . . . . . . . . . Interfaz a la salida. . . . . . . . . . . Salida de resolución de GDG de EQQCLEAN (EQQUXGDG) . . . . . . . . . . . . . Interacciones de DDPROT/DSNPROT . . . . Instalación de la salida . . . . . . . . . Interfaz a la salida. . . . . . . . . . . Salida de incorporación de JCL . . . . . . . Instalación de la salida . . . . . . . . . Interfaz a la salida. . . . . . . . . . . Salida de sustitución de variables (en la variable de definición de trabajos o JCL) . . . . . . . . Instalación de la salida . . . . . . . . . Interfaz a la salida. . . . . . . . . . . Salida de recuperación automática de trabajos . . Instalación de la salida . . . . . . . . . Interfaz a la salida. . . . . . . . . . . Salida de informe de planificación diaria (EQQDPUE1) . . . . . . . . . . . . . Instalación de la salida . . . . . . . . . IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste 232 233 237 237 237 242 242 242 243 243 244 245 245 245 247 248 248 250 250 251 254 254 254 256 256 256 258 258 258 261 262 262 264 264 264 265 265 266 266 267 267 267 269 269 270 272 272 272 274 274 Interfaz a la salida. . . . . . . . . . . Salida de validación de descripción de la aplicación (EQQUXPIF) . . . . . . . . . . . . . Instalación de la salida . . . . . . . . . Interfaz a la salida. . . . . . . . . . . Salida de usuario de System Automation for z/OS (EQQUXSAZ) . . . . . . . . . . . . . Instalación de la salida . . . . . . . . . Interfaz a la salida. . . . . . . . . . . 274 275 275 276 276 277 277 Capítulo 5. Integración con Open Systems . . . . . . . . . . . . . 281 Control de sistemas heterogéneos. . . . . . Configuración del entorno . . . . . . . Envío y seguimiento de la carga de trabajo . Método alternativo para controlar el proceso de VM. . . . . . . . . . . . . . . . Método de uso . . . . . . . . . . . . 281 . 282 . 283 . 283 . 284 Capítulo 6. Notificación de sucesos a Tivoli Workload Scheduler for z/OS . . 289 Suministro de la información de suceso a Tivoli Workload Scheduler for z/OS . . . . . . . Información general sobre subrutinas de Tivoli Workload Scheduler for z/OS . . . . . . Utilización de la subrutina general de Tivoli Workload Scheduler for z/OS (EQQUSIN) . . Requisitos de invocación . . . . . . . Parámetros de EQQUSIN . . . . . . . Especificación de los criterios de selección . . Especificación de los campos de objetos que se actualizarán . . . . . . . . . . . . Códigos de retorno y códigos de razón generados por EQQUSIN . . . . . . . Utilización de subrutinas individuales de Tivoli Workload Scheduler for z/OS . . . . . . . Utilización de EQQUSINB . . . . . . . Utilización de EQQUSINO . . . . . . . Utilización de EQQUSINS . . . . . . . Utilización de EQQUSINT . . . . . . . Utilización de EQQUSINW . . . . . . . . 289 . 290 . . . . 291 291 291 298 . 303 . 306 . . . . . . 307 307 308 310 311 313 Capítulo 7. Utilización de la comprobación de terminación de trabajo . . . . . . . . . . . . . . 317 Tablas de mensajes de JCC . . . Función de registro de incidencias Definición de tablas de mensajes EQQJCCT . . . . . . . . . . . . . . . . . utilizando . . . . . . 317 . 319 . 320 Capítulo 8. Utilización del almacén de datos . . . . . . . . . . . . . . . 327 Visión general . . . . . . . . . . . . . Requisitos previos . . . . . . . . . . . . Instalación del almacén de datos . . . . . . . Ejecución de EQQJOBS para crear ejemplos de instalación . . . . . . . . . . . . . . Estimación del tamaño de los archivos de datos de VSAM del almacén de datos . . . . . . . . 327 329 330 330 331 Archivos de datos . . . . . . . . . . . Índice primario . . . . . . . . . . . . Índice secundario . . . . . . . . . . . Características del almacén de datos local . . . Asignación de VSAM de almacén de datos . . . Archivos de datos . . . . . . . . . . . Índice primario . . . . . . . . . . . . Índice secundario . . . . . . . . . . . Inicialización de archivos de VSAM de almacén de datos . . . . . . . . . . . . . . . . Archivos de datos . . . . . . . . . . . Índice primario . . . . . . . . . . . . Índice secundario . . . . . . . . . . . Acciones posteriores a la instalación en los archivos de VSAM de almacén de datos . . . . . . . Configuración del almacén de datos . . . . . . Sentencias de inicialización del almacén de datos . . . . . . . . . . . . . . . Establecimiento de las sentencias de inicialización del controlador/rastreador UP . . Consideraciones sobre las sentencias RCLOPTS Activación del almacén de datos . . . . . . . 331 332 333 333 333 333 334 334 335 335 335 335 336 336 337 337 337 338 Capítulo 9. Personalización varia . . . 339 Personalización de mensajes de Tivoli Workload Scheduler for z/OS . . . . . . . . . . . Personalización de paneles de Tivoli Workload Scheduler for z/OS . . . . . . . . . . . Personalización del diseño de la lista de finalizados con error y de la lista de preparados . . . . . Invocación del soporte de Hiperbatch . . . . . Personalización del reloj de GMT. . . . . . . Supervisión de los recursos especiales mediante RODM . . . . . . . . . . . . . . . Creación de módulos de definición de código de caso . . . . . . . . . . . . . . . . Invocación del programa de utilidad de supresión de conjuntos de datos . . . . . . . . . . Personalización de Tivoli Workload Scheduler para mensajes en el entorno de capacidades globales con tolerancia a errores . . . . . . . . . . . 339 341 341 342 343 343 346 346 347 Parte 2. Integridad de datos . . . . 349 Capítulo 10. Copia de seguridad y recuperación de conjuntos de datos . 351 Procedimientos de copia de seguridad . . . . . Cómo gestiona Tivoli Workload Scheduler for z/OS la recuperación del plan actual . . . . . Principios de recuperación del plan actual . . . Proceso de recuperación del plan actual . . . Proceso del plan actual durante el inicio de Tivoli Workload Scheduler for z/OS. . . . . Cómo evitar que la copia de seguridad del plan actual resulte dañada . . . . . . . . . . Restauración de un archivo dañado de Tivoli Workload Scheduler for z/OS a partir de la copia de seguridad . . . . . . . . . . . . . Restauración del conjunto de datos de descripción de la estación de trabajo (WS) . . . 351 358 Contenido v 352 353 354 356 357 358 Restauración del conjunto de datos de descripción de la aplicación (AD). . . . . . Restauración del conjunto de datos de instrucción del operador (OI) . . . . . . . Restauración del conjunto de datos de descripción de recurso especial (RD). . . . . Restauración del conjunto de datos de información complementaria (SI) . . . . . . Restauración del conjunto de datos del plan a largo plazo (LPT) . . . . . . . . . . . Restauración del conjunto de datos de repositorio de JCL (JS) . . . . . . . . . Cómo volver a crear el plan actual a partir del plan a largo plazo . . . . . . . . . . . . . Cómo volver a crear el plan actual a partir del nuevo plan actual y del registro de archivado de JT Recuperación de errores en el registro de seguimiento de trabajos . . . . . . . . . . Problemas del conjunto de datos de registro dual de JT . . . . . . . . . . . . . . . . Recuperación de errores en el registro de archivado de JT . . . . . . . . . . . . . . . . Recuperación de errores en el conjunto de datos de punto de comprobación . . . . . . . . . . Recuperación de errores en los conjuntos de datos de suceso. . . . . . . . . . . . . . . Recuperación de errores en un conjunto de datos de envío/liberación . . . . . . . . . . . Recuperación de errores en el conjunto de datos de ampliación del plan actual . . . . . . . . . Recuperación automática de anomalías del controlador . . . . . . . . . . . . . . Notificación de anomalías del controlador . . . Cómo volver a crear el archivo Symphony a partir del plan actual . . . . . . . . . . 359 359 359 360 360 361 361 362 363 363 363 364 365 365 366 366 367 367 Capítulo 11. Limpieza y recuperación de conjuntos de datos del almacén de datos . . . . . . . . . . . . . . . 369 Supresión de datos de la base de datos . . . . . Exportación de datos a un archivo de copia de seguridad . . . . . . . . . . . . . . Importación de datos desde un archivo de copia de seguridad . . . . . . . . . . . . . . Recuperación de anomalía . . . . . . . . . Qué hacer cuando se llenan los archivos de datos Subtarea de limpieza . . . . . . . . . . . 369 vi Consideraciones sobre pruebas de recuperación tras desastre en un entorno global . . . . . . 385 Parte 3. Ajuste . . . . . . . . . . 387 Capítulo 13. Análisis del rendimiento 389 Establecimiento de los objetivos de rendimiento Medición del rendimiento . . . . . . . . . Performance Reporter for MVS y Tivoli Decision Support for OS/390 . . . . . . . . . . RMF . . . . . . . . . . . . . . . ACF/VTAM . . . . . . . . . . . . . VSAM . . . . . . . . . . . . . . . Datos de rendimiento de Tivoli Workload Scheduler for z/OS . . . . . . . . . . 389 390 390 391 393 393 393 Capítulo 14. Actividades básicas de ajuste. . . . . . . . . . . . . . . 395 Recursos del sistema . . . . . . . . Actividad de E/S . . . . . . . . Procesador . . . . . . . . . . Almacenamiento del procesador . . . Indicadores de problemas relacionados con rendimiento . . . . . . . . . . . Cómo evitar cuellos de botella. . . . . . . . . el . . . . . . . . . . 395 395 399 399 . . . 401 . 401 Capítulo 15. Ajuste del controlador y del rastreador . . . . . . . . . . . 403 Ajuste del controlador . . . . . . Envío de trabajos . . . . . . . Seguimiento de trabajos . . . . . Respuesta del diálogo . . . . . Proceso por lotes en segundo plano . . Cómo reconocer los indicadores . . Recomendaciones . . . . . . . Ajuste del rastreador . . . . . . . Creación y comunicación de sucesos. Factores que afectan al rendimiento . JCC . . . . . . . . . . . Reinicio y limpieza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403 403 405 406 406 407 407 407 407 407 408 409 370 371 371 371 372 Capítulo 12. Planificación de recuperación tras desastre . . . . . 373 Diseño de la DRP de Tivoli Workload Scheduler for z/OS . . . . . . . . . . . . . . . . Opciones del centro secundario . . . . . . Estandarización del entorno . . . . . . . Implementación de la DRP de Tivoli Workload Scheduler for z/OS . . . . . . . . . . . Recuperación a proceso de inicio del día . . . Recuperación a un punto de recuperación predefinido . . . . . . . . . . . . . Recuperación a punto de anomalía . . . . . | | Apéndice A. Vectores de alertas genéricas de NetView . . . . . . . . 411 Alerta Alerta Alerta Alerta Alerta Alerta de de de de de de subsistema anómalo . . subtarea anómala . . operación con error . . operación con retraso . larga duración. . . . umbral de cola excedido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411 412 413 413 414 414 373 373 374 Apéndice B. Macros de Tivoli Workload Scheduler for z/OS . . . . 417 376 376 Apéndice C. Biblioteca de ejemplos (SEQQSAMP) . . . . . . . . . . . 419 379 382 Ejemplos de EQQUSIN . . . . . . . . . Salidas de Tivoli Workload Scheduler for z/OS . Salida de inicio o detención . . . . . . IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste . 421 . 422 . 422 Salida de envío de trabajo . . . . . . . . Salida de lectura de biblioteca de trabajos . . . Salida de filtrado de sucesos . . . . . . . Salida de archivado de SYSOUT . . . . . . Salida de creación de registro de incidencia . . Salida de cambio de estado de la operación . . Salida de inicio de la operación . . . . . . Salida de sustitución de variables de JCL . . . Salida de grabación de registro de seguimiento de trabajos . . . . . . . . . . . . . Salida de catálogo de EQQDELDS/EQQCLEAN Salida de resolución de GDG de EQQCLEAN (EQQUXGDG) . . . . . . . . . . . . Salida de validación de descripción de la aplicación . . . . . . . . . . . . . Salida de entorno de planificación por lotes de DP . . . . . . . . . . . . . . . . Salida de prevención de adaptación de trabajos Salida de usuario de operación dependiente del tiempo . . . . . . . . . . . . . . Integración con Open Systems. . . . . . . . Rastreador para VM . . . . . . . . . . 423 423 424 424 424 425 425 426 426 426 426 426 426 427 427 427 427 Rastreador para OS/2 . . . . . . . . . Rastreador para AIX . . . . . . . . . . Paquete de auditoría de Tivoli Workload Scheduler for z/OS . . . . . . . . . . . . . . . Visualización de la salida de la lista de finalizados con error . . . . . . . . . . . . . . . Ejemplos de NetView. . . . . . . . . . . Mensaje WTO de fecha límite . . . . . . . Respuesta a operaciones WTO. . . . . . . Cambio del estado de la operación desde NetView . . . . . . . . . . . . . . Soporte de Hiperbatch de z/OS . . . . . . . Supresión de conjuntos de datos en función de la disposición de JCL y del estado del catálogo . . . Ejemplos varios . . . . . . . . . . . . Ejemplos de actualización MASIVA . . . . . . 428 429 430 433 433 434 434 434 434 435 436 436 Avisos . . . . . . . . . . . . . . 437 Marcas registradas. . . . . . . . . . . . 438 Índice. . . . . . . . . . . . . . . 441 Contenido vii viii IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Figuras 1. 2. 3. 4. Miembro RJJJJ de la biblioteca de JCL de Tivoli Workload Scheduler for z/OS . . . . Utilización de notificación automática de sucesos para controlar operaciones de VM . . Ejemplo de almacenamiento intermedio de EQQUSIN . . . . . . . . . . . . Controlador, rastreador y almacén de datos vista esquemática . . . . . . . . . . © Copyright IBM Corp. 1991, 2011 5. 285 286 292 | | | | 6. 7. Ejemplo de informe de EQQAUDIT: de cabecera . . . . . . . . Ejemplo de informe de EQQAUDIT: de informe . . . . . . . . Ejemplo de informe de EQQAUDIT: de resumen . . . . . . . . página . . . . 431 páginas . . . . 432 página . . . . 433 329 ix x IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Tablas 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. Definición de las sentencias de inicialización adecuadas . . . . . . . . . . . . . 7 Definición de sentencias de inicialización para planificación global con capacidades de tolerancia a errores. . . . . . . . . . . 9 Ejemplos de límite de realimentación . . . . 94 Ejemplos de factores de corrección . . . . 100 Sentencias de inicialización y funciones relacionadas . . . . . . . . . . . . 179 Parámetros relacionados con la configuración 180 Parámetros relacionados con la seguridad 181 Parámetros relacionados con la auditoría 182 Parámetros relacionados con la comprobación de finalización . . . . . . . . . . . 183 Parámetros relacionados con el reinicio y la limpieza . . . . . . . . . . . . . 184 Parámetros relacionados con la recuperación de registros de trabajos del almacén de datos . 185 Parámetros relacionados con la recuperación de trabajos automática . . . . . . . . 185 Parámetros relacionados con el reinicio de cargas de trabajo . . . . . . . . . . 186 Parámetros relacionados con el rendimiento 186 Parámetros relacionados con los informes 187 Parámetros relacionados con RODM . . . . 188 Parámetros relacionados con las salidas 188 Parámetros relacionados con la configuración de la red . . . . . . . . . . . . . 189 Parámetros relacionados con la definición de trabajos . . . . . . . . . . . . . 191 Integración de WLM - parámetros relacionados. . . . . . . . . . . . . 192 Parámetros relacionados con la integración con supervisores externos . . . . . . . 193 Planificación de seguridad . . . . . . . 195 Implementación de seguridad . . . . . . 196 Relación entre productos de seguridad y selecciones de seguridad . . . . . . . . 208 © Copyright IBM Corp. 1991, 2011 25. | 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. Requisitos del acceso para los mandatos TSO de IBM Tivoli Workload Scheduler for z/OS . Recursos fijos y subrecursos protegidos Requisitos de acceso a recursos fijos para usuarios de diálogos . . . . . . . . . Salidas de Tivoli Workload Scheduler for z/OS . . . . . . . . . . . . . . Campos de selección de CP_OPER_EVENT Campos de selección de CP_SR_EVENT Campos de selección de CP_OPINFO_EVENT Campos de selección de BACKUP_EVENT Campos de selección de CP_WS_EVENT Campos de operación que puede actualizar mediante CP_OPER_EVENT . . . . . . Campos de recurso especial que puede actualizar mediante CP_SR_EVENT . . . . Campos de operación que puede actualizar mediante CP_OPINFO_EVENT . . . . . Campos de estación de trabajo que puede actualizar mediante CP_WS_EVENT . . . . Tipos de datos RODM válidos para los subcampos de valor . . . . . . . . . Ciclo de copia de seguridad para DRP a inicio del día. . . . . . . . . . . . Ciclo de copia de seguridad para DRP a punto de recuperación predefinido . . . . Ciclo de copia de seguridad para DRP a punto de anomalía . . . . . . . . . . Alerta de subsistema anómalo . . . . . . Alerta de subtarea anómala . . . . . . . Alerta de operación con error . . . . . . Alerta de operación con retraso . . . . . Alerta de larga duración . . . . . . . . Alerta de umbral de cola excedido . . . . Miembros de la biblioteca SEQQSAMP para personalización y ajuste de Tivoli Workload Scheduler for z/OS . . . . . . . . . 209 210 215 225 299 300 301 302 302 303 304 305 305 345 376 379 382 411 412 413 413 414 414 419 xi xii IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Acerca de esta publicación La publicación IBM® Tivoli Workload Scheduler for z/OS Personalización y ajuste muestra cómo personalizar o realizar los ajustes de IBM Tivoli Workload Scheduler for z/OS. Puede utilizar esta publicación para su consulta durante la instalación. La carga de trabajo se puede ejecutar en diversas plataformas, pero se controla desde un sistema z/OS central que ejecuta el controlador de Tivoli Workload Scheduler for z/OS. En esta publicación, el término planificador, hace referencia a Tivoli Workload Scheduler for z/OS. Y el término DB2 hace referencia a DATABASE 2 y DB2 Universal Database. Novedades de este release Para obtener información sobre las funciones nuevas y modificadas de este release, consulte Tivoli Workload Automation: Visión general. Novedades de esta publicación En esta sección se describe qué ha cambiado en esta publicación desde la versión 8.5.1. El texto modificado o añadido se marca en el margen izquierdo con una barra vertical, excepto para: v Cambios editoriales v El sufijo dependiente de release ha cambiado de I (versión 8.5.1) a J (versión 8.6) para los módulos EQQINITJ, EQQSSCMJ y EQQMINOJ. En esta publicación se describen las siguientes mejoras del producto: v Los registros de trabajo se pueden configurar para que se recuperen automáticamente cuando un trabajo finaliza con error. La recuperación automática del registro de trabajo se puede personalizar también para los trabajos con centro en z que finalizan con error. Puede configurar también la recuperación automática de la información de reinicio para una acción de reinicio y limpieza. Consulte las palabras clave JOBLOGRETRIEVAL y RESTARTINFORETRIEVAL en las sentencias “HTTPOPTS” en la página 68 y “RCLOPTS” en la página 137. v Se han añadido nuevos parámetros a la sentencia HTTPOPTS que le permiten aprovechar el mecanismo de sustitución de variable para los nuevos tipos de trabajo con las opciones avanzadas. Consulte las palabras clave VARTABLES, VARFAIL, VARSUB en la sentencia “HTTPOPTS” en la página 68 para obtener más detalles. v Determine la permanencia de dependencias externas en una operación completada que pertenece a apariciones que aún están activas cuando se envía un trabajo de plan diario y se amplía o planifica de nuevo especificando la palabra clave KEEPCOMPDEPS en la sentencia “BATCHOPT” en la página 26. Esta característica, si se especifica, facilita una operación de nueva ejecución porque las dependencias externas permanecen definidas en la operación cuando se amplía el plan y por lo tanto no se tiene que volver a definirlas. © Copyright IBM Corp. 1991, 2011 xiii A quién va dirigida esta publicación A quién va dirigida esta publicación Esta publicación va dirigida a programadores de sistemas, administradores de seguridad y otro personal que instale, personalice o ajuste IBM Tivoli Workload Scheduler for z/OS. Para utilizar esta publicación de manera eficaz, es necesario que tenga conocimientos prácticos de z/OS y de los conceptos y recursos JES. Debe estar familiarizado con ISPF (Interactive System Productivity Facility), ISPF/PDF (Interactive System Productivity Facility/Program Development) y TSO (Time-Sharing Option). Es recomendable disponer de buenos conocimientos prácticos de VSAM (Virtual Storage Access Method), pero no imprescindible. Para implementar la seguridad, debe conocer RACF (Resource Access Control Facility) o un producto similar. Para implementar salidas o subrutinas de IBM Tivoli Workload Scheduler for z/OS, debe conocer el lenguaje de control de trabajos (JCL) y disponer de buenos conocimientos prácticos de un lenguaje de programación, por ejemplo, un ensamblador o PL/I. Puede utilizar lenguajes de programación que den soporte a convenios de enlace de OS/390 y que puedan cargar y suprimir un programa ensamblador. Publicaciones Puede encontrar información detallada sobre las publicaciones de Tivoli Workload Automation en Tivoli Workload Automation: Publicaciones, . Este documento también contiene información acerca de los convenios utilizados en las publicaciones. Puede encontrar un glosario de los términos utilizados en el producto en Tivoli Workload Automation: Glosario, . Estas son dos publicaciones diferentes del Centro de información. Utilización de LookAt para consultar la explicación de los mensajes LookAt es un recurso en línea que le permite consultar las explicaciones de la mayoría de los mensajes de IBM que encuentre, así como de algunas terminaciones anormales (finalización anormal de una tarea) y códigos del sistema. Utilizar LookAt para buscar información resulta más rápido que la búsqueda convencional, puesto que en la mayoría de los casos LookAt va directamente a la explicación del mensaje. Puede utilizar LookAt desde las siguientes ubicaciones para encontrar explicaciones de mensajes de IBM sobre elementos y funciones de z/OS, z/VM, VSE/ESA y clústeres correspondientes a AIX y Linux: v Internet. Puede acceder a las explicaciones de mensajes de IBM directamente desde el sitio Web de LookAt: http://www.ibm.com/eserver/zseries/zos/ bkserv/lookat/. v El sistema principal de z/OS TSO/E. Puede instalar el código en los sistemas z/OS o z/OS.e para acceder a las explicaciones de los mensajes de IBM, utilizando LookAt desde una línea de mandatos de TSO/E (por ejemplo, indicador de TSO/E, ISPF o z/OS UNIX System Services que ejecuten OMVS). v Su estación de trabajo Microsoft Windows. Puede instalar el código para acceder a las explicaciones de los mensajes de IBM en IBM Online Library z/OS Software Products Collection Kit (SK3T-4270), utilizando LookAt desde una línea de mandatos DOS de Microsoft Windows. xiv IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Utilización de LookAt v El dispositivo portátil inalámbrico. Puede utilizar LookAt Mobile Edition con un dispositivo portátil que tenga acceso inalámbrico y un navegador de Internet (por ejemplo, Internet Explorer para los Pocket PC, Blazer o Eudora para Palm OS u Opera para dispositivos portátiles Linux). Enlace a LookAt Mobile Edition desde el sitio web de LookAt. Puede obtener el código para instalar LookAt en el sistema principal o la estación de trabajo de Microsoft Windows desde un disco de IBM Online Library z/OS Software Products Collection Kit (SK3T-4270) o desde el sitio web de LookAt (pulse en Download y seleccione la plataforma, el release, la colección y la ubicación que se adapta a sus requisitos). Encontrará más información en los archivos LOOKAT.ME disponibles durante el proceso de descarga. Accesibilidad Las características de accesibilidad ayudan a los usuarios con discapacidades físicas como, por ejemplo movilidad o visión limitada, a utilizar productos de software satisfactoriamente. Con este producto, puede utilizar tecnologías de asistencia para oír lo que aparece en la interfaz y navegar por ella. También puede utilizar el teclado en lugar del ratón para utilizar todas las funciones de la interfaz gráfica de usuario. Para obtener información completa sobre la Dynamic Workload Console, consulte el Apéndice de accesibilidad de la publicación Tivoli Workload Scheduler: Guía del usuario y de consulta, SC10-3852. Formación técnica de Tivoli Para obtener información sobre formación técnica de Tivoli, consulte el siguiente sitio web de IBM Tivoli Education: http://www.ibm.com/software/tivoli/education Información sobre soporte Si tiene un problema con el software de IBM, deseará resolverlo con rapidez. IBM facilita las siguientes opciones para obtener el soporte necesario: En línea Vaya al Sitio de soporte de software de IBM en http://www.ibm.com/ software/support/probsub.html y siga las instrucciones. IBM Support Assistant IBM Support Assistant (ISA) es un entorno de trabajo de servicio de software local gratuito que le ayuda a resolver preguntas y problemas relacionados con los productos de software de IBM. ISA proporciona un acceso rápido a la información relacionada con el soporte y herramientas de servicio técnico para la determinación de problemas. Para instalar el software ISA, vaya a http://www.ibm.com/software/support/isa. Troubleshooting Guide Para obtener más información sobre la resolución de problemas, consulte la información de determinación de problemas de este producto. Para obtener más información sobre estas tres maneras de resolver problemas, consulte el apéndice sobre información de soporte en Tivoli Workload Scheduler: Troubleshooting Guide, SC32-1275. Acerca de esta publicación xv Convenios utilizados en esta publicación Convenios utilizados en esta publicación En esta publicación se utilizan varios convenios de tipo de letra para términos y acciones especiales. Los cambios técnicos realizados en el texto se indican mediante una línea vertical a la izquierda del cambio.Estos convenios tienen los significados siguientes: Tipo de información Convenio de estilo Ejemplo Mandatos Todo en letras mayúsculas CREATE Referencias en el texto a campos de paneles Todo en letras mayúsculas QUANTITY Entrada que debe especificarse en los campos de los paneles Monoespaciado MIAPLICACION La primera vez que se introduce un término nuevo Cursiva Aplicación Cómo leer los diagramas de sintaxis A lo largo de esta publicación, la sintaxis se describe en diagramas similares al que aparece a continuación, que describe el mandato SRSTAT TSO: SRSTAT ' nombre de recurso ' SUBSYS( OPCA nombre del subsistema MSTR AVAIL( KEEP RESET NO YES ) DEVIATION( KEEP cantidad RESET ) QUANTITY( KEEP cantidad RESET ) CREATE( YES NO ) TRACE( 0 nivel de rastreo ) Significados de los símbolos: ───── La sentencia empieza aquí. ────── La sentencia continúa en la línea siguiente. ────── La sentencia continúa desde una línea anterior. ───── La sentencia finaliza aquí. xvi ) IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Cómo leer los diagramas de sintaxis Lea los diagramas de sintaxis de izquierda a derecha y de arriba a abajo, siguiendo la ruta de la línea. Los convenios utilizados en los diagramas son los siguientes: v Los elementos necesarios aparecen en la línea horizontal (ruta principal): STATEMENT elemento necesario v Los elementos opcionales aparecen debajo de la ruta principal: STATEMENT elemento opcional v Una flecha que vuelve hacia la izquierda sobre el elemento indica un elemento que se puede repetir. Si se necesita un separador entre elementos, se muestra en la flecha de repetición. , STATEMENT elemento repetible v Si puede elegir entre dos o más elementos, estos aparecen verticalmente en una pila. – Si debe elegir uno de los elementos, un elemento de la pila aparece en la ruta principal: STATEMENT opción necesaria 1 opción necesaria 2 – Si la elección de uno de los elementos es opcional, aparece toda la pila debajo de la ruta principal: STATEMENT opción opcional 1 opción opcional 2 – Una flecha de repetición sobre una pila indica que puede elegir más de un elemento de la pila: , STATEMENT opción opcional 1 opción opcional 2 opción opcional 3 , STATEMENT opción necesaria 1 opción necesaria 2 opción necesaria 3 v Los parámetros que están por encima de la línea principal son parámetros predeterminados: Acerca de esta publicación xvii Cómo leer los diagramas de sintaxis valor predeterminado STATEMENT alternativa v Las palabras clave aparecen en mayúsculas (por ejemplo, STATEMENT). v Los paréntesis y las comas deben especificarse como parte de la sintaxis del mandato, tal y como se muestra. v En mandatos complejos, es posible que los atributos de elementos no quepan en una línea horizontal. Si la línea no se puede dividir, los atributos aparecen al final del diagrama de sintaxis: STATEMENT opción necesaria 1 opción 1 opción necesaria 2 opción necesaria 3 opción 1 opción opcional 1( valor predeterminado alternativa ) valor predeterminado alternativa ) opción 2 opción opcional 2( xviii IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste opción 2 Parte 1. Personalización de IBM Tivoli Workload Scheduler for z/OS | Capítulo 1. Definición de sentencias de inicialización . . . . . . . . . . . . . . 5 Especificación de la sentencia . . . . . . . . . 5 Creación de la sentencia . . . . . . . . . 5 Almacenamiento de sentencias . . . . . . . 6 Alteración temporal de sentencias EQQPARM . . 6 Selección de las sentencias adecuadas . . . . . 6 ALERTS . . . . . . . . . . . . . . . 10 AROPTS . . . . . . . . . . . . . . . 15 AUDIT . . . . . . . . . . . . . . . . 18 AUDITCP . . . . . . . . . . . . . . . 21 AUTHDEF . . . . . . . . . . . . . . 22 BATCHOPT . . . . . . . . . . . . . . 26 CPUREC . . . . . . . . . . . . . . . 38 DBCSOPTS . . . . . . . . . . . . . . 39 DBOPT . . . . . . . . . . . . . . . . 41 DOMREC . . . . . . . . . . . . . . . 44 DSTOPTS . . . . . . . . . . . . . . . 45 DSTUTIL . . . . . . . . . . . . . . . 51 ERDROPTS . . . . . . . . . . . . . . 54 EWTROPTS . . . . . . . . . . . . . . 56 EXITS . . . . . . . . . . . . . . . . 62 FLOPTS . . . . . . . . . . . . . . . 64 HTTPOPTS . . . . . . . . . . . . . . 68 INCLUDE . . . . . . . . . . . . . . . 73 INIT . . . . . . . . . . . . . . . . . 74 INTFOPTS. . . . . . . . . . . . . . . 79 JCCOPTS . . . . . . . . . . . . . . . 81 JTOPTS . . . . . . . . . . . . . . . . 85 MONOPTS . . . . . . . . . . . . . . 111 MONPOL . . . . . . . . . . . . . . 113 NOERROR . . . . . . . . . . . . . . 115 OPCOPTS . . . . . . . . . . . . . . 120 RCLDDP . . . . . . . . . . . . . . . 135 RCLDSNP . . . . . . . . . . . . . . 136 RCLOPTS . . . . . . . . . . . . . . 137 RCLSKIP . . . . . . . . . . . . . . . 144 RESOPTS. . . . . . . . . . . . . . . 146 RESOURCE . . . . . . . . . . . . . . 151 RODMOPTS. . . . . . . . . . . . . . 152 ROUTOPTS . . . . . . . . . . . . . . 156 SERVOPTS . . . . . . . . . . . . . . 161 TCPOPTS . . . . . . . . . . . . . . 166 TOPOLOGY . . . . . . . . . . . . . . 171 TRGOPT . . . . . . . . . . . . . . . 172 TRROPTS . . . . . . . . . . . . . . 174 USRREC . . . . . . . . . . . . . . . 176 XCFOPTS . . . . . . . . . . . . . . 177 Capítulo 2. Identificación de sentencias-parámetros de inicialización relacionados . . . . . . . . . . . . . 179 Configuración . . . . . . . . . . . . . 180 Seguridad . . . . . . . . . . . . . . 181 © Copyright IBM Corp. 1991, 2011 Generación de información de auditoría (datos de registro JT) . . . . . . . . . . . . . Determinación del éxito o fracaso de un trabajo Recuperación . . . . . . . . . . . . Reinicio y limpieza . . . . . . . . . Recuperación de registros de trabajo. . . . Recuperación automática de trabajos . . . Reinicio de la carga de trabajo. . . . . . Rendimiento. . . . . . . . . . . . . Generación de informes . . . . . . . . . Supervisión de RODM . . . . . . . . . Proceso de salida . . . . . . . . . . . Planificación global con capacidades de tolerancia a errores . . . . . . . . . . . . . . Configuración de red . . . . . . . . . Definiciones de trabajo . . . . . . . . Ajustes regionales . . . . . . . . . . Página de códigos . . . . . . . . . Huso horario . . . . . . . . . . Integración de WLM . . . . . . . . . . Supervisión externa . . . . . . . . . . . 182 182 . 183 . 184 . 185 . 185 . 186 . 186 . 187 . 188 . 188 . . . . . . . . 189 189 191 191 191 192 192 193 Capítulo 3. Implementación de seguridad . . . Planificación de la implementación de seguridad Cómo Tivoli Workload Scheduler for z/OS verifica la autorización de acceso . . . . . . Identificación de usuarios . . . . . . . . Establecimiento de convenios de denominación para recursos de IBM Tivoli Workload Scheduler for z/OS . . . . . . . . . . . . . . Agrupación de usuarios y recursos de RACF Consideraciones generales de seguridad . . . Control del acceso a Tivoli Workload Scheduler for z/OS . . . . . . . . . . . . . . . . Control del acceso al subsistema Tivoli Workload Scheduler for z/OS . . . . . . . Control del acceso a recursos fijos de Tivoli Workload Scheduler for z/OS . . . . . . . Control del acceso a subrecursos de Tivoli Workload Scheduler for z/OS . . . . . . . Subrecursos y recursos de RACF de Tivoli Workload Scheduler for z/OS . . . . . . Control del acceso a Tivoli Workload Scheduler for z/OS desde APPC . . . . . . . . . APPC/z/OS y RACF . . . . . . . . . API de Tivoli Workload Scheduler for z/OS y RACF . . . . . . . . . . . . . Control del acceso a Tivoli Workload Scheduler for z/OS utilizando Dynamic Workload Console Creación de la clase TMEADMIN para asociar a un ID de usuario de RACF . . . Utilización de un nuevo parámetro de inicialización de servidor para asociar un ID de usuario de RACF . . . . . . . . . 195 195 196 197 198 198 199 200 200 201 201 202 203 204 204 205 206 208 1 Cómo permitir acceso al controlador mediante Dynamic Workload Console . . ID de usuario implicados en Dynamic Workload Console . . . . . . . . . Control del acceso mediante mandatos TSO . Funciones y datos que puede proteger . . . . Requisitos de acceso a recursos fijos para usuarios de diálogos . . . . . . . . . . . . . Ejemplos de estrategias de seguridad . . . . Estrategia de seguridad centralizada. . . . Acceso externo a IBM Tivoli Workload Scheduler for z/OS . . . . . . . . Acceso mediante el subsistema IBM Tivoli Workload Scheduler for z/OS . . . . . Estrategia de seguridad descentralizada . . Acceso externo a IBM Tivoli Workload Scheduler for z/OS . . . . . . . . Acceso mediante el subsistema IBM Tivoli Workload Scheduler for z/OS . . . . . . 208 . 208 . 209 . 210 . 215 . 219 . 219 . 219 . 220 . 221 . 221 . 221 Capítulo 4. Salidas de Tivoli Workload Scheduler for z/OS . . . . . . . . . . . Invocación de las salidas de usuario de Tivoli Workload Scheduler for z/OS . . . . . . . . Salida de inicio/detención (EQQUX000) . . . Salida de envío de trabajo (EQQUX001) . . . Salida de lectura de biblioteca de trabajos (EQQUX002) . . . . . . . . . . . . Salida de información de descripción de la aplicación (EQQUX003) . . . . . . . . . Salida de filtrado de sucesos (EQQUX004). . . Salida de archivado de SYSOUT (EQQUX005) Salida de creación de registro de incidencia (EQQUX006) . . . . . . . . . . . . Salida de cambio de estado de la operación (EQQUX007) . . . . . . . . . . . . Salida de iniciación de la operación (EQQUX009) . . . . . . . . . . . . Salida de grabación de registro de seguimiento de trabajos (EQQUX011) . . . . . . . . . Salida de prevención de adaptación de trabajos (EQQUX013) . . . . . . . . . . . . Salida de operación dependiente del tiempo (EQQUX014) . . . . . . . . . . . . Salida de incorporación de JCL (en directiva FETCH) . . . . . . . . . . . . . . Salida de sustitución de variables (en la variable de definición de trabajos o JCL) . . . . . . Salida de recuperación automática de trabajos (en la sentencia RECOVER). . . . . . . . Salida de informe de planificación diaria (EQQDPUE1) . . . . . . . . . . . . Salida de catálogo EQQDELDS/EQQCLEAN (EQQUXCAT) . . . . . . . . . . . . Salida de resolución de GDG de EQQCLEAN (EQQUXGDG) . . . . . . . . . . . . Validación de descripción de la aplicación (EQQUXPIF) . . . . . . . . . . . . Salida de entorno de planificación diaria EQQDPX01 . . . . . . . . . . . . . Instalación de la salida . . . . . . . . 2 225 227 227 227 227 227 227 227 228 228 228 228 228 228 228 229 229 229 229 229 229 229 229 Interfaz a la salida. . . . . . . . . . Salida de inicio/detención de Tivoli Workload Scheduler for z/OS (EQQUX000) . . . . . . . Instalación de la salida . . . . . . . . . Interfaz a la salida. . . . . . . . . . . Salida de envío de trabajo (EQQUX001) . . . . Instalación de la salida . . . . . . . . . Interfaz a la salida. . . . . . . . . . . Salida de lectura de biblioteca de trabajos (EQQUX002) . . . . . . . . . . . . . Instalación de la salida . . . . . . . . . Interfaz a la salida. . . . . . . . . . . Salida de información de descripción de la aplicación (EQQUX003) . . . . . . . . . . Instalación de la salida . . . . . . . . . Interfaz a la salida. . . . . . . . . . . Salida de filtrado de sucesos (EQQUX004). . . . Instalación de la salida . . . . . . . . . Interfaz a la salida. . . . . . . . . . . Salida de archivado de SYSOUT (EQQUX005) . . Instalación de la salida . . . . . . . . . Interfaz a la salida. . . . . . . . . . . Salida de creación de registro de incidencia (EQQUX006) . . . . . . . . . . . . . Instalación de la salida . . . . . . . . . Interfaz a la salida. . . . . . . . . . . Salida de cambio de estado de la operación (EQQUX007) . . . . . . . . . . . . . Instalación de la salida . . . . . . . . . Interfaz a la salida. . . . . . . . . . . Salida de iniciación de la operación (EQQUX009) Instalación de la salida . . . . . . . . . Interfaz a la salida. . . . . . . . . . . Salida de grabación de registro de seguimiento de trabajos (EQQUX011) . . . . . . . . . . . Instalación de la salida . . . . . . . . . Interfaz a la salida. . . . . . . . . . . Salida de suceso de adaptación de trabajos (EQQUX013) . . . . . . . . . . . . . Instalación de la salida . . . . . . . . . Interfaz a la salida. . . . . . . . . . . Salida de operación dependiente del tiempo (EQQUX014) . . . . . . . . . . . . . Instalación de la salida . . . . . . . . . Interfaz a la salida. . . . . . . . . . . Ejemplo . . . . . . . . . . . . . Limitaciones. . . . . . . . . . . . Salida de catálogo EQQDELDS/EQQCLEAN (EQQUXCAT) . . . . . . . . . . . . . Instalación de la salida . . . . . . . . . Interfaz a la salida. . . . . . . . . . . Salida de resolución de GDG de EQQCLEAN (EQQUXGDG) . . . . . . . . . . . . . Interacciones de DDPROT/DSNPROT . . . . Instalación de la salida . . . . . . . . . Interfaz a la salida. . . . . . . . . . . Salida de incorporación de JCL . . . . . . . Instalación de la salida . . . . . . . . . Interfaz a la salida. . . . . . . . . . . Salida de sustitución de variables (en la variable de definición de trabajos o JCL) . . . . . . . . IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste 230 231 231 231 232 232 233 237 237 237 242 242 242 243 243 244 245 245 245 247 248 248 250 250 251 254 254 254 256 256 256 258 258 258 261 262 262 263 264 264 264 264 265 265 266 266 267 267 267 269 Instalación de la salida . . . . . . . . . Interfaz a la salida. . . . . . . . . . . Salida de recuperación automática de trabajos . . Instalación de la salida . . . . . . . . . Interfaz a la salida. . . . . . . . . . . Salida de informe de planificación diaria (EQQDPUE1) . . . . . . . . . . . . . Instalación de la salida . . . . . . . . . Interfaz a la salida. . . . . . . . . . . Salida de validación de descripción de la aplicación (EQQUXPIF) . . . . . . . . . . . . . Instalación de la salida . . . . . . . . . Interfaz a la salida. . . . . . . . . . . Salida de usuario de System Automation for z/OS (EQQUXSAZ) . . . . . . . . . . . . . Instalación de la salida . . . . . . . . . Interfaz a la salida. . . . . . . . . . . 269 270 272 272 272 274 274 274 275 275 276 276 277 277 Capítulo 5. Integración con Open Systems . . 281 Control de sistemas heterogéneos. . . . . . . 281 Configuración del entorno . . . . . . . . 282 Envío y seguimiento de la carga de trabajo . . 283 Método alternativo para controlar el proceso de VM. . . . . . . . . . . . . . . . . 283 Método de uso . . . . . . . . . . . . 284 Capítulo 6. Notificación de sucesos a Tivoli Workload Scheduler for z/OS . . . . . . Suministro de la información de suceso a Tivoli Workload Scheduler for z/OS . . . . . . . Información general sobre subrutinas de Tivoli Workload Scheduler for z/OS . . . . . . Utilización de la subrutina general de Tivoli Workload Scheduler for z/OS (EQQUSIN) . . Requisitos de invocación . . . . . . . Parámetros de EQQUSIN . . . . . . . APP - sección fija . . . . . . . . . APPOBJ - sección de objeto. . . . . . APPSEL - sección de la selección . . . . APPVAL - sección del valor de la selección APPFLD - sección del campo . . . . . APPDAT - sección de datos . . . . . Especificación de los criterios de selección . . Selección de una operación para cambiar el estado (CP_OPER_EVENT) . . . . . . Selección de un recurso especial (CP_SR_EVENT) . . . . . . . . . Selección de una operación para proporcionar datos de usuario (CP_OPINFO_EVENT) . . . . . . . Selección de un conjunto de datos de Tivoli Workload Scheduler for z/OS (BACKUP_EVENT) . . . . . . . . Selección de una estación de trabajo (CP_WS_EVENT) . . . . . . . . . Especificación de los campos de objetos que se actualizarán . . . . . . . . . . . . Actualización del estado de la operación (CP_OPER_EVENT) . . . . . . . . Actualización de un recurso especial (CP_SR_EVENT) . . . . . . . . . . 289 . 289 . 290 Actualización de un campo de datos de usuario (CP_OPINFO_EVENT) . . . . Actualización de una estación de trabajo (CP_WS_EVENT) . . . . . . . . . Códigos de retorno y códigos de razón generados por EQQUSIN . . . . . . . Utilización de subrutinas individuales de Tivoli Workload Scheduler for z/OS . . . . . . . Utilización de EQQUSINB . . . . . . . Requisitos de invocación . . . . . . Parámetro EQQUSINB . . . . . . . Utilización de EQQUSINO . . . . . . . Requisitos de invocación . . . . . . Parámetros de EQQUSINO . . . . . . Utilización de EQQUSINS . . . . . . . Requisitos de invocación . . . . . . Parámetros de EQQUSINS . . . . . . Utilización de EQQUSINT . . . . . . . Requisitos de invocación . . . . . . Parámetros de EQQUSINT . . . . . . Utilización de EQQUSINW . . . . . . . Requisitos de invocación . . . . . . Parámetros de EQQUSINW . . . . . . 305 . 305 . 306 . . . . . . . . . . . . . . . . 307 307 307 307 308 308 308 310 310 310 311 311 311 313 314 314 Capítulo 7. Utilización de la comprobación de terminación de trabajo. . . . . . . . . . 317 Tablas de mensajes de JCC . . . . . . . . . 317 Función de registro de incidencias . . . . . . 319 Definición de tablas de mensajes utilizando EQQJCCT . . . . . . . . . . . . . 320 Capítulo 8. Utilización del almacén de datos Visión general . . . . . . . . . . . . . Requisitos previos . . . . . . . . . . . . Instalación del almacén de datos . . . . . . . Ejecución de EQQJOBS para crear ejemplos de instalación . . . . . . . . . . . . . . Estimación del tamaño de los archivos de datos de VSAM del almacén de datos . . . . . . . . Archivos de datos . . . . . . . . . . . Archivos de datos no estructurados . . . . Archivos de datos estructurados . . . . . Índice primario . . . . . . . . . . . . Ejemplo . . . . . . . . . . . . . Índice secundario . . . . . . . . . . . Características del almacén de datos local . . . Asignación de VSAM de almacén de datos . . . Archivos de datos . . . . . . . . . . . Índice primario . . . . . . . . . . . . Índice secundario . . . . . . . . . . . Inicialización de archivos de VSAM de almacén de datos . . . . . . . . . . . . . . . . Archivos de datos . . . . . . . . . . . Índice primario . . . . . . . . . . . . Índice secundario . . . . . . . . . . . Acciones posteriores a la instalación en los archivos de VSAM de almacén de datos . . . . . . . Configuración del almacén de datos . . . . . . Sentencias de inicialización del almacén de datos . . . . . . . . . . . . . . . 327 327 329 330 Parte 1. Personalización de IBM Tivoli Workload Scheduler for z/OS 3 . . . . . . 291 291 291 292 294 296 297 . 297 . 298 . 298 . 299 . 300 . 301 . 302 . 302 . 303 . 303 330 331 331 331 332 332 333 333 333 333 333 334 334 335 335 335 335 336 336 337 . 304 Establecimiento de las sentencias de inicialización del controlador/rastreador UP . . 337 Consideraciones sobre las sentencias RCLOPTS 337 Activación del almacén de datos . . . . . . . 338 Capítulo 9. Personalización varia . . . . . . Personalización de mensajes de Tivoli Workload Scheduler for z/OS . . . . . . . . . . . Personalización de paneles de Tivoli Workload Scheduler for z/OS . . . . . . . . . . . Personalización del diseño de la lista de finalizados con error y de la lista de preparados . . . . . Invocación del soporte de Hiperbatch . . . . . Personalización del reloj de GMT. . . . . . . Supervisión de los recursos especiales mediante RODM . . . . . . . . . . . . . . . Creación de módulos de definición de código de caso . . . . . . . . . . . . . . . . Invocación del programa de utilidad de supresión de conjuntos de datos . . . . . . . . . . Personalización de Tivoli Workload Scheduler para mensajes en el entorno de capacidades globales con tolerancia a errores . . . . . . . . . . . 4 339 339 341 341 342 343 343 346 346 347 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Capítulo 1. Definición de sentencias de inicialización Este capítulo describe las sentencias de inicialización de Tivoli Workload Scheduler for z/OS que se pueden definir para personalizar su trabajo. Proporciona información para especificar las sentencias, y una descripción detallada para cada una de ellas. Las sentencias se muestran en orden alfabético. Los diagramas describen la sintaxis de cada sentencia. Para obtener una descripción de diagramas de sintaxis, consulte “Cómo leer los diagramas de sintaxis” en la página xvi. Especificación de la sentencia La sentencias de inicialización determinan las tareas que inicia Tivoli Workload Scheduler for z/OS, cómo Tivoli Workload Scheduler for z/OS procesa el trabajo y las funciones que se puede utilizar. Este capítulo describe las reglas de sintaxis para crear sentencias, donde almacena las sentencias, y las sentencias que puede seleccionar para un comprobador de seguimiento, un controlador, un almacén de datos, un lote o una aplicación PIF. Creación de la sentencia Para personalizar las funciones de Tivoli Workload Scheduler for z/OS debe establecer las sentencias de inicialización del conjunto de datos de la biblioteca PARMLIB. Las sentencias se componen de un nombre de sentencia, palabras clave y valores de palabra clave, y sigue las reglas de sintaxis del mandato TSO: v Los datos de las sentencias deben estar en las columnas 1 a 72. La información de las columnas 73 a 80 se ignora. v Una sentencia no puede superar 455 registros. v Una sentencia sólo puede especificarse una vez, a menos que se indique lo contrario. Si se especifica más de una instancia de sentencia, sólo se tendrá en cuenta la última. No se informa de mensaje de aviso en EQQMLOG. v Una palabra clave puede especificarse en una sentencia sólo una vez, a menos que se indique lo contrario. Si se especifica más de una instancia de palabra clave en la misma sentencia, sólo se tendrá en cuenta la última. No se informa de mensaje de aviso en EQQMLOG. v Un espacio en blanco o una coma sirve como delimitador entre dos palabras clave; si suministra más de un delimitador, los delimitadores extra serán ignorados. v Los valores de las palabras clave están entre paréntesis. Si una palabra clave puede tener múltiples valores, la lista de valores debe estar separada por delimitadores válidos. No se aceptan delimitadores entre una palabra clave y el paréntesis izquierdo del valor especificado. v Algunas palabras clave tienen múltiples valores. Si desea utilizar el valor predeterminado para un valor que aparece antes del que se está especificando explícitamente, use el delimitador mostrado en la sintaxis de la palabra clave. Por ejemplo, si especifica TRACK(READYFIRST) en la sentencia JTOPTS, se utiliza TODOS de modo predeterminado para el primer valor. © Copyright IBM Corp. 1991, 2011 5 Creación de las sentencias v Escriba /* para iniciar un comentario y */ para finalizarlo. Un comentario puede realizar registros distribuidos de las imágenes del miembro del parámetro y puede aparecer en cualquier sitio excepto en medio de una palabra clave o un valor especificado. v Antes del nombre de sentencia de un registro sólo pueden aparecer sentencias de comentario. v Una sentencia continúa hasta la siguiente sentencia o hasta el final de registros en el miembro. Los caracteres de continuación no se utilizan para definir una sentencia que distribuya registros de parámetros. v Puede abreviar palabras clave hasta la longitud no ambigua más pequeña en la sentencia actual. Los nombres de sentencias no pueden abreviarse. Notas: 1. Si una abreviación coincide con más de una palabra clave en una sentencia, Tivoli Workload Scheduler for z/OS escribe al registro de mensaje el mensaje analizador TSO El parámetro IKJ56704I ES AMBIGUO. Esto puede hacer que una subtarea finalice o que finalice Tivoli Workload Scheduler for z/OS. 2. Los nombres de clases, objetos y campos RODM son sensibles a mayúsculas y minúsculas. Asegúrese de preservar el caso si especifica sentencias RODMOPTS en la biblioteca de parámetros. Además, si un nombre no contiene caracteres alfanuméricos o nacionales, debe adjuntar el nombre en comillas dobles. Almacenamiento de sentencias Las sentencias de inicialización de Tivoli Workload Scheduler for z/OS se almacenan en una biblioteca de parámetros identificada por la sentencia EQQPARM DD en el procedimiento JCL (lenguaje de control de trabajos). Esta biblioteca es un conjunto de datos particionados con una longitud de registro lógico de 80 bytes. Cuando inicia Tivoli Workload Scheduler for z/OS, se lee un miembro de la biblioteca que contiene sentencias de inicialización. Este miembro es identificado por el parámetro PARM en la sentencia EXEC PGM=EQQMAJOR del procedimiento JCL. Alteración temporal de sentencias EQQPARM Cuando utiliza la interfaz de programa (PIF) de Tivoli Workload Scheduler for z/OS, puede especificar un segundo archivo de parámetros en la sentencia EQQYPARM DD del JCL o de la aplicación PIF. Éste puede ser un miembro de un conjunto de datos particionados o un archivo secuencial. EQQYPARM contiene una sentencia de inicialización, INIT, que altera temporalmente los valores establecidos por la sentencia INTFOPTS en EQQPARM. Selección de las sentencias adecuadas Las sentencias que se definen determinan las funciones de Tivoli Workload Scheduler for z/OS que puede utilizar. La Tabla 1 en la página 7 muestra qué sentencia puede definir para un comprobador de seguimiento, un controlador, un servidor, un almacén de datos, un lote o una aplicación PIF. Para un controlador en reposo, especifique las sentencias de controlador. | | | | | Para utilizar la opción de plan de extremo a extremo debe también definir las sentencias de definiciones de trabajo para estaciones de trabajo no tolerantes a errores en la biblioteca SCRPTLIB tal y como se describe en Tabla 2 en la página 9. 6 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Alteración temporal de sentencias EQQPARM Tabla 1. Definición de las sentencias de inicialización adecuadas Nombre Comprobador de seguimiento ALERTS U Almacén Controlador Servidor de datos Proceso por lotes PIF Especifica opciones para U Generación de NetView, IBM Tivoli Monitoring, registro de mensajes y alertas WTO. AROPTS U Recuperación automática de trabajos. AUDIT U Creación de información de auditoría para cambios a datos de Tivoli Workload Scheduler for z/OS. AUDITCP U Creación de información de auditoría para los cambios de estado automáticos de una condición de operación en el plan actual. U Comprobación de seguridad. AUTHDEF U BATCHOPT U Especificación de opciones para todos los trabajos por lotes. CPUREC U Especificación de las opciones de configuración para una estación de trabajo no tolerante a errores. DBCSOPTS Opción de idioma japonés. U DBOPT U DOMREC U Generación de informes de Dynamic Workload Console U Definición de un dominio para red de agentes distribuidos. DSTOPTS U Especificación de opciones para el almacén de datos. DSTUTIL U Especificación de opciones para los programas de utilidad de lotes del almacén de datos y la subtarea de limpieza (CleanUp). ERDROPTS U EWTROPTS U EXITS U U Tarea del lector de sucesos. Tarea del grabador de sucesos. U Llamada a las salidas de Tivoli Workload Scheduler for z/OS. FLOPTS U Comunicación con el almacén de datos (permitiendo la recuperación del registro de trabajo y las funciones de reinicio y limpieza). HTTPOPTS U Seguimiento de trabajos en ejecución en agentes z-centric y para recuperar sus registros de ejecución de trabajos. INCLUDE U Miembros de definición de tabla NOERROR. Capítulo 1. Definición de sentencias de inicialización 7 Alteración temporal de sentencias EQQPARM Tabla 1. Definición de las sentencias de inicialización adecuadas (continuación) Nombre Comprobador de seguimiento Almacén Controlador Servidor de datos INIT U INTFOPTS JCCOPTS Proceso por lotes Especifica opciones para U Opciones de tiempo de ejecución para procesar solicitudes desde una aplicación PIF y un servidor. Solicitudes desde interfaces de programación (requerido). U Comprobación de terminación de trabajo. U JTOPTS U Determinación del comportamiento de las operaciones en las estaciones de trabajo y cómo se envían y se controlan. MONOPTS U Habilitación de supervisión por parte de un agente externo. Usado por IBM Tivoli Monitoring. MONPOL U Definición de la política de supervisión que debe ser usada por las supervisiones externas. NOERROR U Tratamiento de los códigos de error de rastreo de trabajos como códigos de terminación normales. U Inicio de subtareas de Tivoli Workload Scheduler for z/OS. RCLDDP U Listado de DDnames protegidos RCLDSNP U Listado de nombre de conjuntos de datos protegidos. RCLOPTS U Definición de las opciones usadas durante las funciones de reinicio y de limpieza. RCLSKIP U Listado de las INCLUDE para mantenerlas al principio de un JCL cuando es adaptado por la función de reinicio y limpieza. RESOPTS U Control de recursos especiales OPCOPTS U RESOURCE | | | | PIF U Definición de para qué recursos especiales debe producir informes la planificación diaria. RODMOPTS U Supervisión de los recursos especiales mediante RODM. ROUTOPTS U Rutas de comunicación a comprobador de seguimiento, el agente z-centric y destinos de motores remotos. 8 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Alteración temporal de sentencias EQQPARM Tabla 1. Definición de las sentencias de inicialización adecuadas (continuación) Nombre Comprobador de seguimiento Almacén Controlador Servidor de datos SERVOPTS TCPOPTS U U U U TRGOPT U U U Tarea de comunicación TCP/IP local. También puede definirla en el archivo EQQYPARM al que se hace referencia en el procedimiento inicio de sesión del usuario. Especificación de opciones de configuración para planificación global con capacidades de tolerancia a errores. Soporte a la automatización de carga de trabajo controlada por sucesos. La usa el programa Java que crea archivos de configuración para el desencadenamiento de conjuntos de datos. La ruta de comunicación al controlador. U U U Especifica opciones para Definición de opciones para un servidor. U USRREC XCFOPTS PIF U TOPOLOGY TRROPTS Proceso por lotes Definición local del ID de usuario y la contraseña que deben usarse para operaciones ejecutadas en estaciones de trabajo no tolerantes a errores. Comunicaciones XCF. U Tabla 2 muestra las sentencias que se deben definir para los trabajos que se ejecutan en las estaciones de trabajo con tolerancia a errores. Para obtener información detallada, consulte Tivoli Workload Scheduler for z/OS: Planificación global con capacidades de tolerancia a errores. Tabla 2. Definición de sentencias de inicialización para planificación global con capacidades de tolerancia a errores. Nombre Descripción JOBREC Propiedades de trabajos de estaciones de trabajo no tolerantes a errores VARSUB Opciones de sustitución de variables RECOVERY Recuperación para trabajos cuyo estado sea de error y el código de error no sea FAIL Consulte las secciones siguientes para obtener una sintaxis detallada y una descripción de cada sentencia de inicialización, en una lista en orden alfabético. Capítulo 1. Definición de sentencias de inicialización 9 ALERTS ALERTS Propósito La sentencia ALERTS especifica las condiciones bajo las que Tivoli Workload Scheduler for z/OS debe generar una alerta. Puede especificar esta sentencia para un comprobador de seguimiento, controlador o controlador en reposo. Puede usar estas acciones de alerta cuando se produzca una condición de alerta: v Enviar una alerta genérica a NetView. v Grabar un mensaje en el registro de mensajes de Tivoli Workload Scheduler for z/OS. v Generar un mensaje WTO (write-to-operator). v Enviar una alerta a IBM Tivoli Monitoring (Tivoli Enterprise Portal). ALERTS se define en el miembro de la biblioteca EQQPARM tal y como se especifica con el parámetro PARM de la sentencia JCL EXEC. Formato ALERTS , GENALERT( DURATION ERROROPER LATEOPER OPCERROR QLIMEXCEED ) OPCERROR , , MONALERT( MLOG( DURATION ERROROPER LATEOPER QLIMEXCEED RESCONT ) DURATION ERROROPER LATEOPER OPCERROR QLIMEXCEED SPECRES WLMOPER YES NO MONOPER( ) RECEIVERID( NETVALRT identificador de receptor de alerta ) , WTO( 10 ) DURATION ERROROPER LATEOPER OPCERROR QLIMEXCEED RESCONT ) IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste ALERTS Parámetros GENALERT(condición de error,...,condición de error) Define las condiciones bajo las que Tivoli Workload Scheduler for z/OS debe enviar una alerta genérica a NetView. MLOG(condición de error,...,condición de error|OPCERROR) Define las condiciones bajo las que Tivoli Workload Scheduler for z/OS debe grabar un mensaje en el registro de mensajes. MONALERT(condición de error,...,condición de error) Define las condiciones bajo las que Tivoli Workload Scheduler for z/OS envía una alerta genérica al agente IBM Tivoli Monitoring. Este parámetro sólo es significativo si se proporciona la sentencia MONOPTS. MONOPER(YES|NO) Define si las siguientes condiciones de error especificadas en el parámetro MONALERT son sólo para trabajos de supervisión (predeterminado) o para todos los trabajos. Las condiciones de error son ERROROPER, LATEOPER, DURATION y WLMOPER. RECEIVERID(Identificador de receptor de alerta|NETVALRT) Define el destinatario de alertas NetView al que se envían las alertas genéricas. Especifique esta palabra clave si el destinatario de alertas en el espacio de direcciones de NetView que maneja la automatización de alertas de Tivoli Workload Scheduler for z/OS no tiene el ID predeterminado de NetView, NETVALRT. WTO(condición de error,...,condición de error) Define las condiciones bajo las que Tivoli Workload Scheduler for z/OS debe generar un mensaje WTO (write-to-operator). Condiciones de Error Puede especificar una o más de las siguientes condiciones de error para cada tipo de alerta. Recuerde que sólo OPCERROR y QLIMEXCEED son aplicables a un comprobador de seguimiento; otras condiciones de error serán ignoradas si las especifica. DURATION La acción de alerta se realiza cuando una operación del plan actual está activa demasiado tiempo. Esto significa que una operación que haya sido iniciada (estado extendido S) debe estar activa más tiempo que su duración estimada multiplicado por uno de los valores siguientes: v El límite de acciones de alerta establecido para ALEACTION (para obtener detalles, consulte “JTOPTS” en la página 85). -Ov El límite de la realimentación de duración establecido para LIMFDBK (para obtener detalles, consulte “JTOPTS” en la página 85). Este valor se utiliza si no se establece ALEACTION. y luego se divide entre 100. Por ejemplo, si una operación tiene una duración estimada de 10 minutos y la acción de alerta es 200, la acción de alerta se realiza si la operación está activa más de 20 minutos. La acción de alerta también se realiza si se ha iniciado la operación pero el trabajo asociado o la tarea iniciada todavía no ha comenzado después de 10 minutos (no se ha recibido ningún suceso A2/B2), es decir, la Capítulo 1. Definición de sentencias de inicialización 11 ALERTS operación ha tenido un estado / estado extendido SU y SQ totalmente durante más de 10 minutos. La acción de alerta se realiza sólo en operaciones que tengan estado de iniciadas. Para acciones de alerta MLOG y WTO, se emite un mensaje EQQE028I para una operación en una estación de trabajo general y EQQE038I para una operación en una estación de trabajo de ordenador o de impresora durante operaciones prolongadas. El mensaje EQQE039I se emite para operaciones de ordenador que hayan sido enviadas pero no se hayan iniciado. Notas: 1. El valor utilizado para seleccionar las operaciones para las que se debe emitir una alerta de larga duración se establece con la palabra clave ALEACTION en la sentencia JTOPTS. Si no se especifica ALEACTION, el valor establecido para LIMFDBK se utiliza en su lugar. En este caso, el valor para el límite de retroalimentación que puede especificar opcionalmente en la descripción de la aplicación se omite. 2. Si el límite de acciones de alerta es 0 o el límite de acciones de alerta no se ha especificado y el límite de retroalimentación es 0, la acción de alerta se realiza cuando una operación está activa más de su duración estimada. 3. Si la duración estimada de una operación es 99 horas, 59 minutos y 01 segundos, no se envía alerta de duración para esta operación. ERROROPER La acción de alerta se realiza cuando una operación del plan actual está establecida con estado de terminada en en error. Para acciones de alerta MLOG y WTO, se emite un mensaje EQQE026I para una operación en una estación de trabajo general, y EQQE036I para una operación en una estación de trabajo de ordenador o de impresora. LATEOPER La acción de alerta se realiza cuando una operación del plan actual se produce tarde. Una operación es considerada como tarde si alcanza su hora de inicio y no tiene el estado de iniciada, terminada o eliminada. Para acciones de alerta MLOG y WTO, se emite un mensaje EQQE027I para una operación en una estación de trabajo general y EQQE037I para una operación en una estación de trabajo de ordenador o de impresora. Nota: Use LATEOPER sólo cuando las horas límite sean exactas porque puede afectar al rendimiento de Tivoli Workload Scheduler for z/OS. OPCERROR La acción de alerta se realiza cuando una subtarea de Tivoli Workload Scheduler for z/OS o un subsistema de Tivoli Workload Scheduler for z/OS finaliza repentinamente. Para acciones de alerta MLOG y WTO, se emiten los mensajes EQQZ045W y EQN019E. Si se especifica la acción GENALERT y se produce la condición de alerta EQQN019E, entonces se envía la alerta de subtarea anómala a NetView. NetView. Nota: OPCERROR siempre está en vigor para MLOG. QLIMEXCEED La acción de alerta se realiza cada vez que una cola de subtarea de Tivoli Workload Scheduler for z/OS supera el valor de umbral. Excepto para la cola de grabador de sucesos, los valores de umbral son múltiplos de 10 entre el 10% y 90%, y después el 95% y 99%. Tivoli Workload Scheduler for z/OS comprueba el tamaño de una cola cuando se añade a ella un suceso. Excepto 12 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste ALERTS para la cola del grabador de sucesos, las cola de subtarea de Tivoli Workload Scheduler for z/OS pueden contener hasta 32 000 elementos. El tamaño de la cola del grabador d sucesos se determina con el ECSA que se asigna. La cola se comprueba cada vez que el grabador de sucesos va a leer sucesos; la acción de alerta se realiza si la cola supera el 50%. Si la cola del grabador de sucesos se llena, se emite un mensaje indicando cuántos sucesos se han perdido. El valor de la alerta muestra el porcentaje real usado, que será superior al valor de umbral. Para acciones de alerta MLOG y WTO, se emite el mensaje EQQZ106W. RESCONT Puede especificar RESCONT (contención de recursos) sólo para tipos de alerta MLOG y WTO. La acción de alerta se realiza cuando una operación ha estado esperando en una cola de recursos el tiempo especificado en la palabra clave CONTENTIONTIME de RESOPTS. Se emite el mensaje EQQQ515W. SPECRES La acción de alerta se realiza cuando el tiempo que se va a asignar a un recurso dado a la operación del plan actual supera el tiempo especificado por el parámetro RESOPTS CONTENTIONTIME. Esta alerta tiene efecto cuando se define en el parámetro MONALERT. WLMOPER La acción de alerta se realiza cuando una operación en el plan actual es promovida por WLM. La alerta se envía sólo si se especifica en el parámetro MONALERT. Ejemplos ALERTS MLOG(ERROROPER,LATEOPER,DURATION) 1 WTO(DURATION) 2 GENALERT(ERROROPER) 3 MONALERT(DURATION,OPCERROR,WLMOPER)4 MONOPER(YES) 5 En este ejemplo de una sentencia ALERTS: 1 Tivoli Workload Scheduler for z/OS graba un mensaje en el registro de mensajes para operaciones establecidas como terminadas en error, que llegan tarde o están activas demasiado tiempo. Aunque no se especifica, la condición OPCERROR también es aplicable para la acción de alerta MLOG. 2 Un mensaje WTO (write-to-operator) se general en operaciones que están activas demasiado tiempo. 3 Tivoli Workload Scheduler for z/OS envía una alerta genérica a NetView para operaciones con estado de terminada en error. De modo predeterminado, se envían alertas genéricas al destinatario de alertas NETVALRT. 4 Tivoli Workload Scheduler for z/OS envía una alerta genérica a IBM Tivoli Monitoring para operaciones que tienen largas duraciones, para subtareas o subsistemas de Tivoli Workload Scheduler for z/OS que finalizan inesperadamente y para operaciones promovidas por WLM. 5 Tivoli Workload Scheduler for z/OS envía una alerta genérica a IBM Tivoli Monitoring sólo para operaciones supervisadas (operaciones con Capítulo 1. Definición de sentencias de inicialización 13 ALERTS EXTERNAL MONITOR = YES) que cumplen las condiciones especificadas en el parámetro MONALERT y no para todos los trabajos. 14 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste AROPTS AROPTS Propósito La sentencia AROPTS define las opciones de tiempo de ejecución para la recuperación automática de trabajos y de tareas iniciadas. Es usado por un controlador o controlador en reposo donde se especifica OPCOPTS RECOVERY(YES). AROPTS se define en el miembro de la biblioteca EQQPARM tal y como se especifica con el parámetro ARPARM de la sentencia OPCOPTS. Formato AROPTS JCLUSER GROUP JCLEDITOR OWNER AUTHUSER( ) CHKRESTART( NO YES ) ENDTIME( 2359 hhmm ) EXCLUDECC( NOAR code ) 6 código de retorno sin recuperación más alto EXCLUDERC( ) PREDWS( nombre de estación de trabajo predecesora ) STARTTIME( 0000 hhmm ) USERREQ( NO YES ) Parámetros AUTHUSER(GROUP|JCLEDITOR|OWNER|JCLUSER) Define dónde Tivoli Workload Scheduler for z/OS debe recuperar el nombre usado para la comprobación de aurotidad en la recuperación automática: GROUP El identificador de grupo de autoridad de la aparición anómala. JCLEDITOR El nombre en el archivo de repositorio del JCL (EQQJSnDS). Si el JCL no ha sido actualizado mediante los diálogos o la interfaz de programa (PIF), Tivoli Workload Scheduler for z/OS no realiza la comprobación de autoridad. El nombre de la estadística ISPF de la biblioteca de trabajos (EQQJBLIB) no se usa. OWNER El identificador de propietario de la aparición anómala. El identificador de propietario es truncado si tiene más de 8 caracteres. JCLUSER El nombre del usuario que creó o actualizó por última vez el JCL. JCLUSER es el valor predeterminado. Si el JCL no ha sido actualizado mediante los diálogos o la interfaz de programa Capítulo 1. Definición de sentencias de inicialización 15 AROPTS (PIF), Tivoli Workload Scheduler for z/OS usa el nombre de la estadística ISPF de la biblioteca de trabajos (EQQJBLIB). Si no existen estadísticas, Tivoli Workload Scheduler for z/OS no realiza la comprobación de autoridad. CHKRESTART(YES/NO) Normalmente la función de recuperación automática retrasa las acciones de recuperación, siempre que el tipo de limpieza es Inmediata, hasta que las acciones de limpieza han sido terminadas con éxito. Esto se hace incluso si las acciones de recuperación no necesitan que se se reinicie la operación, por ejemplo cuando ADDAPPL es la acción de recuperación requerida. Es el comportamiento predeterminado y corresponde a AROPTS CHKRESTART(NO). Si desea que se produzca el mecanismo de retraso (esperar a que finalicen las acciones de limpieza) sólo cuando las acciones de recuperación requieren el reinicio de un trabajo o paso, debe especificar AROPTS CHKRESTART(YES). Cuando se especifica AROPTS CHKRESTART(YES), y las acciones de recuperación no requieren un reinicio, las acciones de recuperación se realizan inmediatamente y después comienzan las acciones de limpieza inmediatas, pero no se espera a su terminación. Los tipos de limpieza Ninguna e Inmediata son compatibles con la recuperación automática en todos los escenarios. Los tipos de limpieza Manual y Automática sólo son compatibles con recuperación automática si se especifica AROPTS CHKRESTART(YES) y las acciones de recuperación no requieren el reinicio de un trabajo o paso (la recuperación continúa en este caso). Si se especifica AROPTS CHKRESTART(NO), o las acciones de recuperación requieren el reinicio de un trabajo o paso y el tipo de limpieza de la operación anómala es Manual o Automática, la función de recuperación automática emite el mensaje de error correspondiente y detiene el proceso de la operación en cuestión. ENDTIME(hhmm|2359) Define el final del intervalo de tiempo para el que se realiza recuperación automática para trabajos y tareas iniciadas que contienen una sentencia RECOVER sin una especificación TIME. Este modo predeterminado de hora final de día se especifica con el formato hhmm, donde hh es la hora en el rango 00–23, y mm son los minutos en el rango 00–59. EXCLUDECC(code|NOAR) Define un código de error individual o un código de caso para el que no se realiza recuperación automática a menos que sea solicitado explícitamente por una sentencia RECOVER en el trabajo anómalo la tarea iniciada. Un código de caso es un grupo de terminación anómala y códigos de retorno. Los códigos de caso se definen en el módulo EQQCASEM usando el macro EQQCASEC. El código de caso predeterminado es NOAR, el cual contiene S122, S222, CAN, JCLI, JCL y JCCE. Para obtener más información sobre los códigos de caso, consulte “Creación de módulos de definición de código de caso” en la página 346. EXCLUDERC(código máximo de retorno sin recuperación|6) Define el valor de código de terminación de paso máximo para el que no se realiza recuperación automática a menos que sea solicitado explícitamente por una sentencia RECOVER en el trabajo anómalo o la tarea iniciada. PREDWS(nombre de estación de trabajo predecesora) Define un nombre de estación de trabajo predecesora usada por la recuperación automática para crear una dependencia externa cuando una 16 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste AROPTS aparición predecesora a una operación anómala se añade al plan actual. Se usa el modo predeterminado si no se encuentra operación predecesora. Esto puede ocurrir, por ejemplo, si se ha eliminado una operación o se ha cambiado el nombre de una estación de trabajo. El número más alto de operación de la aparición predecesora con un nombre de estación de trabajo que coincida con la definición PREDWS queda configurada como la predecesora. Si no se especifica PREDWS o si no hay coincidencia en el nombre de estación de trabajo, se usa el punto final de la aparición predecesora para establecer la dependencia. Si la aparición predecesora contiene varios puntos finales, se usa el punto final con el número de operación más alto. El nombre de estación de trabajo puede especificarse de modo genérico. STARTTIME(hhmm|0000) Define el inicio del intervalo de tiempo para el que se realiza recuperación automática para trabajos y tareas iniciadas que contienen una sentencia RECOVER sin una especificación TIME. La hora de inicio predeterminada se especifica con el formato hhmm, donde hh es la hora en el rango 00–23, y mm son los minutos en el rango 00–59. USERREQ(YES|NO) Define si debe permitirse que la recuperación automática actualice el plan actual cuando no puede establecerse un identificador de usuario o cuando el identificador de usuario es desconocido para el producto de seguridad. El valor especificado por AUTHUSER determina dónde Tivoli Workload Scheduler for z/OS intenta recuperar un nombre para la comprobación de autoridad. Especifique YES si es necesario un identificador de usuario válido. Especifique NO si debe permitirse que la recuperación automática actualice el plan actual, incluso aunque no haya disponible un identificador de usuario o sea desconocido para el producto de seguridad. NO es el valor predeterminado. Ejemplos AROPTS STARTTIME(0800) ENDTIME(1700) 1 2 En este ejemplo de sentencia AROPTS, los trabajos y las tareas iniciadas que contienen una sentencia RECOVER sin una especificación TIME sólo son recuperadas si fallan entre 0800 y 1700. Capítulo 1. Definición de sentencias de inicialización 17 AUDIT AUDIT Propósito La sentencia AUDIT define cómo se registran los cambios a los datos de Tivoli Workload Scheduler for z/OS. Puede especificar esta sentencia para un controlador o controlador en reposo. También puede usar más de una sentencia AUDIT para definir acciones de auditoría de Tivoli Workload Scheduler for z/OS. Cuando se registra un acceso, se graba un registro con información de auditoría en el conjunto de datos de registro de rastreo de trabajos. La correlación de los registros en el conjunto de datos de registro de rastreo de trabajos se describe en Diagnosis Guide and Reference Cuando se solicita el registro de accesos a los datos del JCL, el registro se realiza si el JCL está presente o insertado en el repositorio del JCL. Notas: 1. Los cambios a los registro del plan actual, la extensión del plan actual y el desencadenante de sucesos se registran siempre para el reinicio de Tivoli Workload Scheduler for z/OS. Los accesos leídos a estos recursos no son registrados, y no se puede evitar el registro cronológico de los accesos actualizados. 2. Debido a que los registros de auditoría se graban en el conjunto de datos del registro de rastreo de trabajos, afectan a la frecuencia con la que Tivoli Workload Scheduler for z/OS realiza un proceso de copia de seguridad del plan actual. Recuerde esto cuando especifique un valor para la palabra clave BACKUP de JTOPTS. Tenga también en cuenta los registros de auditoría cuando asigne los conjuntos de datos de registros de rastreo de trabajos, en especial si especifica AMOUNT(DATA). 3. Los registros AUDIT contienen un campo para indicar si están relacionados con un cambio de datos real. Basándose en ese campo, el programa EQQAUDIT informa sólo de aquellos registros que han cambiado desde un punto de vista externo. Por ejemplo, cuando un usuario de diálogo selecciona un elemento de datos de una lista mediante el comando de fila M (Modificar) y sale usando la clave PF3, sin cambiar el elemento de datos, el proceso vuelve a grabar los registros de datos relacionados para mantener cualquier cambio realizado por el planificador por motivos internos. En este caso, el planificador crea un registro AUDIT para un elemento de datos que el usuario externo n cambió realmente, sin embargo EQQAUDIT no informa de ese registro. En particular, usando el comando de la fila J siempre hace que el JCL sea grabado al archivo JS, incluso si el usuario de diálogo no ha cambiado el JCL. La biblioteca de muestras de Tivoli Workload Scheduler for z/OS contiene un programa que puede formatear informes de rastreo de trabajos y de registros de auditoría. Consulte “Paquete de auditoría de Tivoli Workload Scheduler for z/OS” en la página 430 para obtener más información. AUDIT se define en el miembro de la biblioteca EQQPARM tal y como se especifica con el parámetro PARM de la sentencia JCL EXEC. Formato AUDIT ACCESS( 18 UPDATE READ ) IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste AMOUNT( KEY DATA ) AUDIT | FILE( ALL AD CAL JLIB JS JV LT OI PER RD VAR WS WSCL ) Parámetros ACCESS(READ|UPDATE) Define cuándo Tivoli Workload Scheduler for z/OS debe realizar rastreo de accesos al archivo. Especifique UPDATE para realizar rastreo de todos los cambios realizados al archivo. Especifique READ para realizar rastreo a todos los accesos. AMOUNT(DATA|KEY) Define cuántos datos deben ser registrados por Tivoli Workload Scheduler for z/OS para accesos al archivo. Especifique KEY para registrar sólo la clave VSAM. Esto es suficiente para identificar el recurso. Especifique DATA para registrar la clave VSAM y el registro. | | FILE(nombre del archivo IBM Tivoli Workload Scheduler for z/OS) Define el nombre del archivo para el que se está definiendo la auditoría. Es necesaria una sentencia AUDIT independiente para identificar cada archivo para el que se desea registrar la información de auditoría. Especifique uno de los nombres: AD Descripción de la aplicación CAL Definición del calendario JLIB JCL en una biblioteca de trabajos JS JCL en el archivo JS VSAM JV Tabla de variables JCL LT Aparición de plan a largo plazo OI Instrucción de operación PER Definición de período RD Descripción de recursos especiales VAR Valor de variables JCL WS Descripción de estación de trabajo WSCL Definición de todas las estaciones de trabajo cerradas ALL Todos los archivos Ejemplos AUDIT FILE(ALL) ACCESS(UPDATE) AMOUNT(KEY) AUDIT FILE(JS) ACCESS(UPDATE) AMOUNT(DATA) 1 2 En este ejemplo de sentencias AUDIT: 1 Tivoli Workload Scheduler for z/OS realiza rastreo de todos los cambios a todos los archivos realizando un registro cronológico de la clave VSAM. Capítulo 1. Definición de sentencias de inicialización 19 AUDIT 2 20 Tivoli Workload Scheduler for z/OS realiza rastreo de todos los cambios al JCL para trabajos y tareas iniciadas realizando un registro cronológico de la clave VSAM y el registro. IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste AUDITCP AUDITCP Propósito Use la sentencia AUDITCP para activar o desactivar el proceso de seguimiento automáticamente realizado por el planificador, en relación con el cambio de estado de una condición de operación en el plan actual. Las sentencias siguientes son opcionales porque los registros TRL relacionados se utilizan sólo para supervisar y no para el procesamiento de reaplicación de JT. Formato AUDITCP CONDSTATUS( NO YES ) NO YES CDEPSTATUS( ) CDEPSTEPEND( NO YES ) UNEXPECTEDRC( NO YES ) Parámetros CONDSTATUS(YES|NO) Si establece este parámetro en YES, cada vez que cambie automáticamente el estado de una condición, el planificador crea un registro de datos TRLBDY45 en el registro de JT. Si utiliza el valor predeterminado, el planificador realiza el proceso estándar para los registros de TRLBDY45, que los crea sólo para realizar el seguimiento del cambio de estado de las condiciones después de una solicitud MCP. CDEPSTATUS(YES|NO) Si establece este parámetro en YES, cada vez que se cambie el estado de una dependencia de condición, el planificador crea un registro de datos TRLBDY44 en el registro de JT. Si utiliza el valor predeterminado, el planificador realiza el proceso estándar para los registros de TRLBDY44, que los crea sólo para realizar el seguimiento del cambio de estado de las dependencias de las condiciones después de una solicitud MCP. CDEPSTEPEND(YES|NO) Si establece este parámetro en YES, cada vez que ser reciba un suceso de final de paso y que se encuentre en el plan una dependencia de condición a la que haga referencia, el planificador crea un registro de datos TRLBDY49 en el registro de JT. Si utiliza el valor predeterminado, no se crean los registros TRLBDY49. UNEXPECTEDRC(YES|NO) Si establece este parámetro en YES, cada vez que se produce una situación de RC inesperado (se envían mensajes EQQE141W, EQQE142W o EQQM215W en el controlador MLOG) el planificador crea un registro de datos TRLBDY50 en el registro de JT. Si utiliza el valor predeterminado TRLBDY50, no se crean registros. Capítulo 1. Definición de sentencias de inicialización 21 AUTHDEF AUTHDEF Propósito La sentencia AUTHDEF especifica los recursos de Tivoli Workload Scheduler for z/OS definidos en un producto de seguridad. Puede especificar esta sentencia para un controlador, un controlador en reposo o un comprobador de seguimiento. AUTHDEF se define en el miembro de la biblioteca EQQPARM tal y como se especifica con el parámetro PARM de la sentencia JCL EXEC. Formato AUTHDEF CLASS( 22 OPCCLASS nombre de la clase de recurso IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste ) AUTHDEF | ALL FIRST NONE LISTLOGGING( , ) SUBRESOURCES( AD.ADNAME AD.ADGDDEF AD.GROUP AD.JOBNAME AD.NAME AD.OWNER AD.SECELEM AD.UFVAL CL.CALNAME CP.ADNAME CP.CPGDDEF CP.GROUP CP.JOBNAME CP.NAME CP.OWNER CP.SECELEM CP.UFVAL CP.WSNAME CP.ZWSOPER ET.ADNAME ET.ETNAME JL.DSNAME JL.MEMBER JS.ADNAME JS.GROUP JS.JOBNAME JS.OWNER JS.WSNAME JV.OWNER JV.TABNAME LT.ADNAME LT.LTGDDEF LT.OWNER OI.ADNAME PR.PERNAME RD.RDNAME RL.ADNAME RL.GROUP RL.OWNER RL.WSNAME RL.WSSTAT SR.SRNAME WS.WSNAME ) TRACE( 0 4 8 ) Parámetros CLASS(nombre de la clase de recurso|OPCCLASS) Define el nombre de la clase de recurso de seguridad que protege los recursos de Tivoli Workload Scheduler for z/OS. El valor es válido hasta que se especifica un valor diferente y se reinicia el espacio de direcciones de Tivoli Workload Scheduler for z/OS. Capítulo 1. Definición de sentencias de inicialización 23 AUTHDEF Recuerde la siguiente lista de comprobación cuando use este parámetro: v La clase de recursos debe definirse en el descriptor de clase RACF y las tablas de direccionamiento. v Las definiciones nuevas en el descriptor de clase RACF y las tablas de direccionamiento requieren una IPL (carga de programa inicial). v Si varios subsistemas de controlador requieren políticas independientes, requieren clases independientes. v IBMOPC es una clase predefinida que puede usarse sin necesidad de una IPL si sólo se requiere una clase. v Después de la migración de RACF, considere redefinir cualquier clase definida en una versión anterior de RACF. v La clase predeterminada OPCCLASS no está todavía definida en RACF. Antes de usar esta clase, asegúrese de que existan las entradas necesarias en el descriptor de clase RACF y las tablas de direccionamiento. LISTLOGGING(FIRST|NONE|ALL) En el perfil de recursos se define cómo se registran los datos para los accesos a un recurso. Si restringe el acceso a los datos de Tivoli Workload Scheduler for z/OS en el nivel de registro especificando subrecursos, una solicitud para mostrar los datos de Tivoli Workload Scheduler for z/OS puede hacer que e registren varias violaciones de acceso para esos registros que cumplen los criterios de filtro pero a los que el usuario no tiene acceso. LISTLOGGING le permite cambiar la cantidad de datos registrados para solicitudes de listas. Especifique FIRST cuando el registro cronológico deba ser realizado sólo para el primero intento de lectura a un recurso. El registro cronológico se produce sólo para la primera entrada que tenga un perfil, el cual especifica que debe producirse el registro cronológico. Especifique NONE si no debe realizarse registro cronológico. Especifique ALL si debe producirse registro cronológico tal y como se especifica en el perfil para el recurso. ALL es el valor predeterminado. SUBRESOURCES(recurso,...,recurso) Define si Tivoli Workload Scheduler for z/OS comprueba en el nivel de registro si un usuario está autorizado a acceder a la información de un archivo VSAM de Tivoli Workload Scheduler for z/OS. La lista de recursos puede contener uno o más de los elementos mostrados en el diagrama de sintaxis. Siempre que un usuario accede a un registro, por ejemplo en el archivo AD, Tivoli Workload Scheduler for z/OS comprueba si el usuario está autorizado a acceder al registro del modo intencionado. Para hacerlo, se genera un nombre de recurso, y se envía una solicitud mediante SAF (system authorization facility) al sistema de seguridad para comprobar la autoridad del usuario. Por ejemplo, si se especifica AD.ADNAME, se recupera el nombre de la aplicación desde el registro, y el prefijo ADA. se añade para crear el nombre de recurso. El sistema de seguridad es posteriormente llamado para comprobar si existe el recurso en la clase de recursos definida por la palabra clave CLASS y si el usuario está autorizado para acceder a ella. La lista de recursos predeterminada para la palabra clave SUBRESOURCES es la lista vacía. Esto significa que lo predeterminado es usar autoridad ya establecida y no comprobar la autoridad del usuario para acceder a registros VSAM individuales. Nota: Si ha especificado OPCHOST(NO) en la sentencia OPCOPTS, sólo son relevantes los subrecursos RL.WSNAME, RL.WSSTAT y SR.SRNAME. AD.SECELEM y CP.SECELEM son relevantes sólo si se ejecuta System 24 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste AUTHDEF Automation versión 3.1 (con el nivel de mantenimiento apropiado instalado) o posterior. Cuando se establecen, protegen toda la información de System Automation en el segmento AD y el registro CP33, respectivamente. TRACE(4|8|0) Define si Tivoli Workload Scheduler for z/OS graba información de rastreo al registro de mensajes (EQQMLOG) cada vez que se invoca el macro RACROUTE. Especifique 0, que es el valor predeterminado, si no desea rastrear la información. Especifique 4 si desea información de rastreo parcial. Especifique 8 si desea información de rastreo total. Ejemplos AUTHDEF CLASS(OPCCLASS) SUBRESOURCES(AD.ADNAME,WS.WSNAME) 1 2 En este ejemplo de una sentencia AUTHDEF: 1 Se usa la clase de recursos predeterminada. 2 Tivoli Workload Scheduler for z/OS verificará la autorización para descripciones de aplicaciones (comprobando el nombre de aplicación) y estaciones de trabajo (comprobando el nombre de estación de trabajo). Capítulo 1. Definición de sentencias de inicialización 25 BATCHOPT BATCHOPT Propósito La sentencia BATCHOPT define las opciones de tiempo de ejecución para los trabajos por lotes de Tivoli Workload Scheduler for z/OS. BATCHOPT se define en su propio miembro de la biblioteca EQQPARM. El miembro es referenciado por el trabajo por lotes de Tivoli Workload Scheduler for z/OS en tiempo de ejecución. Formato BATCHOPT DEFAULT nombre de calendario CALENDAR( ) NO YES CHECKSUBSYS( ) CKPTREFRESH( NO YES ) CONTROLLERTOKEN( este subsistema nombre de subsistema ) NO YES CRITOPMSGS( ) AA/MM/DD formato de fecha en informes DATEFORM( ) DB2AVAIL( STOP CONTINUE ) DB2SYSTEM( subsistema DB2 ) DPALG( 2 algoritmo de planificación diaria DPROUT( SYSPRINT ddname de informe de plan diario ) ) YES NO DYNAMICADD( ) DYNAMICDEL( HDRS( NO YES ) GLOBAL identificador de tabla GTABLE( lista de líneas de cabecera de informe ) ) JRUNHISTORY( NO YES STOP CONTINUE , ) KEEPCOMPDEPS( NO YES ) LOGID( 01 identificador en conjunto de datos de registro de rastreo ) LTPDEPRES( YES NO MAXOCCNUM( 32767 nnnnnnn ) MAXHISTORYROWS( 5000 número de filas ) 26 ) NCPTROUT( IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste YES NO ) OCPTROUT( NO YES CMP ) BATCHOPT OPERDALL( N Y PAGESIZE( 55 tamaño de página para informes PLANHOUR( 6 inicio de período de planificación ) OPERHISTORY( NO YES ) N Y OPERIALL( ) ) ) PREDWS( nombre de estación de trabajo predecesora ) PREVRES( YES NO ) RCLEANUP ( NO YES ) 0 días RETAINOPER( ) SUBSYS( OPCA nombre de subsistema SUCCWS( nombre de estación de trabajo sucesiva predeterminada ) ) TPLGYPRM( TPLGPARM nombre de miembro ) VALEACTION( ABEND END WARN ) Parámetros CALENDAR(nombre de calendario|DEFAULT) Define el calendario predeterminado de Tivoli Workload Scheduler for z/OS. Puede especificar un nombre, de 1 a 16 caracteres, que haga referencia a un calendario de la base de datos de calendarios. Las funciones de planificación de Tivoli Workload Scheduler for z/OS usan este calendario: v Durante el proceso por lotes de planes a largo plazo para determinar días de ejecución para una aplicación si no se especifica un calendario en la descripción de la aplicación. v Al ampliar el plan actual si los parámetros de entrada especificados indican que sólo deben tenerse en cuenta días laborables en el período ampliado. v Durante el proceso de planificación a largo plazo y Actualización masiva para validar que las opciones EVERY especificadas para un ciclo de ejecución de una aplicación son consistentes con el tiempo final del día laborable del calendario de la aplicación. Si no se especifica un calendario predeterminado, o si el calendario especificado no existe en la base de datos de calendario, se usa un calendario con el nombre DEFAULT como calendario predeterminado. Si no existe ningún calendario con el nombre DEFAULT, todos los días son considerados días laborables y el tiempo final del día laborable se establece como 00.00. Si no existe el calendario especificado en la base de datos de calendario, Actualización masiva no comprueba las opciones EVERY. CHECKSUBSYS(YES|NO) Controla si el programa de planificación diaria debe comprobar que puede sincronizar con el proceso en el espacio de direcciones del controlador. Capítulo 1. Definición de sentencias de inicialización 27 BATCHOPT La sincronización se realiza usando el bloqueo ENQ con ámbito SYSTEMS. La sincronización puede fracasar porque: v El controlador no ha sido iniciado. v El controlador no se está ejecutando dentro del mismo complejo GRS que el programa de planificación diaria. v La palabra clave SUBSYS no identifica el controlador correcto. Si se especifica NO o se selecciona de modo predeterminado, los dos últimos casos crearán un registro de estado corrupto en el archivo de punto de comprobación, y el plan actual nuevo no será sustituido por el controlador. Entonces es necesaria la recuperación manual, y los archivos del plan actual pueden estar corruptor. Especifique YES para que finalice el programa de planificación diaria si el controlador de Tivoli Workload Scheduler for z/OS especificado por la clave SUBSYS no puede alcanzarse cuando la planificación diaria solicita que los subsistemas se preparen para el proceso de planificación. Cuando se especifica NO o se selecciona de modo predeterminado, el programa de planificación diaria sigue con el proceso si no puede alcanzarse el controlador. Asegúrese de que esto ocurra sólo porque no se haya iniciado el subsistema. CKPTREFRESH(YES|NO) Este parámetro puede usarse para renovar el conjunto de datos de punto de comprobación durante una ampliación de la planificación diaria o una nueva planificación de las entradas anteriores que ya no estén "en uso". Nota: El valor predeterminado es NO y el conjunto de datos de punto de comprobación mantiene un registro de cada destino remoto definido en ROUTOPTS y conectado al menos una vez con el controlador. Por lo tanto, si se van a añadir nuevos destinos o a cambiar algunos nombres ya definidos en las sentencias ROUTOPTS, es aconsejable establecer este parámetro a YES al menos una vez después de completar los cambios planificados. El mensaje EQQN036I puede ayudar a determinar cuándo el límite de 1000 se está acercando y sugiere que es hora de renovar el conjunto de datos de punto de comprobación. CONTROLLERTOKEN(nombre de subsistema|este subsistema) Este parámetro se usa para la función de historial. El nombre de subsistema es una clave para la información de historial. Cuando el plan actual es ampliado, se usa el valor BATCHOPT CONTROLLERTOKEN para grabar la información. Cuando se recupera la información de la base de datos, se usa el valor OPCOPTS CONTROLLERTOKEN, así se pueden volver a ejecutar trabajos iniciados desde el plan actual de otro subsistema (por ejemplo, cuando un sistema en reposo sustituye al principal) especificando la señal correcta después de la sustitución. Si especifica OPERHISTORY(NO) u omite la palabra clave OPERHISTORY, se ignora la palabra clave CONTROLLERTOKEN. CRITOPMSGS(NO|YES) Este parámetro se usa para filtrar los mensajes emitidos para operaciones que faltan en la hora límite. Especifique YES para emitir mensajes de horas límite faltantes que hagan referencia sólo a operaciones con el campo CRITICAL establecido como P o W. Especifique NO para emitir mensajes de horas límite faltantes que hacen referencia a cualquier tipo de operación. El valor predeterminado es NO. 28 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste BATCHOPT DATEFORM(formato de fecha en informes|AA/MM/DD) Especifica el formato de fecha usado en informes. Puede especificar cualquier combinación de siglo (CC), año (YY), mes (MM) y día (DD). CC es opcional. También puede usar el número de día (DDD) del calendario juliano en lugar del mes y el día. El delimitador puede ser cualquier carácter distinto de C, Y, M, o D. Sin embargo, si especifica CCYYMMDD, en cualquier orden, no puede usar delimitadores. DB2AVAIL(CONTINUE|STOP) Esta palabra clave se usa para la función de historial. Especifica las acciones que Tivoli Workload Scheduler for z/OS realiza si el subsistema DB2 no está disponible. Si especifica STOP, Tivoli Workload Scheduler for z/OS graba un mensaje de error DB2 al conjunto de datos EQQMLOG, y si se amplia el plan actual, se detiene con el código de retorno 8. Si especifica OPERHISTORY(NO) u omite la palabra clave OPERHISTORY, se ignora la palabra clave DB2AVAIL. DB2SYSTEM(subsistema DB2) Esta palabra clave es necesaria para la función de historial. Especifica el subsistema DB2, igual que en el miembro IEFSSNxx de SYS1.PARMLIB. Si especifica OPERHISTORY(YES) pero omite la palabra clave DB2SYSTEM, se emite un mensaje de error. Si especifica OPERHISTORY(NO) u omite la palabra clave OPERHISTORY, se ignora la palabra clave DB2SYSTEM. DPALG(algoritmo de planificación diaria|2) Determina cuánto influye la prioridad de una aplicación en el modo en que es planificada. Los valores aceptables van de 0 a 32 767. Un valor 0 significa que se descarta la prioridad; 2 ofrece un equilibrio razonable ente prioridades y tiempos de sin operación; y 32 767 significa que las operaciones se ordenan sólo según prioridad. DPROUT(ddname de informe de planificación diaria|SYSPRINT) Especifica el ddname que Tivoli Workload Scheduler for z/OS usa al producir informes de planificación diaria. DYNAMICADD(NO|YES) DYNAMICADD determina si Tivoli Workload Scheduler for z/OS crea un recurso especial durante la planificación si una operación necesita un recurso que no está definido en la base de datos de recursos especiales. Especifique YES si desea que Tivoli Workload Scheduler for z/OS cree un recurso en el plan actual. La base de datos de recursos especiales no se actualiza. Especifique NO si Tivoli Workload Scheduler for z/OS no debe crear dinámicamente un recurso. Tivoli Workload Scheduler for z/OS planifica la operación como si no usa el recurso. Un recurso creado dinámicamente tiene estos valores: Recurso especial El nombre especificado por la operación de asignación. Texto En blanco. ID de grupo Rec Espec En blanco. Hiperbatch No. Capítulo 1. Definición de sentencias de inicialización 29 BATCHOPT Usado para Planificación y control. En error En blanco.Si se produce un error, Tivoli Workload Scheduler for z/OS usa el valor especificado en los detalles de operación o, si este campo está en blanco, el valor de la palabra clave ONERROR de RESOPTS. Valores predeterminados El recurso tiene estos valores predeterminados para cantidad y disponibilidad: Intervalos Cantidad La cantidad especificada en la primera operación de asignación. La cantidad aumenta si más operaciones planean asignar el recurso especial al mismo tiempo. Tivoli Workload Scheduler for z/OS aumenta la cantidad sólo para recursos creados dinámicamente para evitar contención. Disponible Sí. No se crean intervalos. Los valores predeterminados especifican la cantidad y disponibilidad. Estaciones de trabajo El recurso tiene el valor predeterminado *, lo cual significa todas las estaciones de trabajo. Las operaciones de todas las estaciones de trabajo pueden asignar el recurso. Consulte también la palabra clave DYNAMICADD de RESOPTS en la página 146, la cual controla la creación dinámica de recursos especiales sin definir en al plan actual. DYNAMICDEL(YES|NO) DYNAMICDEL determina si un recurso especial que ha sido añadido dinámicamente al plan actual puede suprimirse si se cambia el plan actual sin comprobar las condiciones normales mostradas en la sección "configuración de los valores globales" del manual Managing the Workload. Especifique NO si los cambios añadidos dinámicamente pueden suprimirse cuando se cambie el plan actual. Especifique YES si los cambios añadidos dinámicamente pueden suprimirse cuando se cambie el plan actual sin hacer más comprobaciones. Nota: Es muy aconsejable que especifiquen DYNAMICDEL(YES) todos los usuarios que usen de manera significativa la adición dinámica de recursos especiales. Si los registros añadidos dinámicamente no se suprimen usando esta característica, el tamaño del espacio de datos sigue aumentando con el tiempo con una degradación de rendimiento inicial que empeora hasta que se agota el espacio disponible y el trabajo por lotes finaliza con la terminación anómala 01D. GTABLE(identificador de tabla|GLOBAL) Define el nombre de la tabla de variables globales para el complejo de Tivoli Workload Scheduler for z/OS cuando se planifica en un entorno global con tolerancia a errores. Esta tabla contiene definiciones de variables que pueden usarse para cualquier operación dentro del complejo de Tivoli Workload Scheduler for z/OS. Se busca la tabla de variables globales cuando no puede encontrarse una tabla (o variable dentro de una tabla) a la que hace referencia una operación. Debe establecer esta palabra clave con el mismo valor que la 30 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste BATCHOPT palabra clave GTABLE en la sentencia OPCOPTS (para obtener más detalles consulte GTABLE en la página 125). El valor de esta palabra clave se especifica en el parámetro TABLES de la sentencia SCRPTLIB VARSUB (para obtener detalles consulte la descripción de esta sentencia en el manual Tivoli Workload Scheduler for z/OSPlanificación global con capacidades de tolerancia a errores) y se procesa durante la ejecución de los trabajos por lotes de la planificación diaria. Se ignora si no se usa la característica de planificación global con capacidades de tolerancia a errores. Puede especificar sólo un identificador de tabla para el complejo de Tivoli Workload Scheduler for z/OS. Tivoli Workload Scheduler for z/OS usa el nombre predeterminado GLOBAL si no se especifica un identificador de tabla. HDRS(lista de líneas de cabeceras de informes|) Define una lista de series de caracteres que contienen cabeceras de informes. La longitud máxima de cada cabecera de informe es de 120 bytes. El trabajo por lotes no usa más de tres cabeceras de informes. representa una línea en blanco y es la cabecera de informe predeterminada. Si usa la opción de idioma japonés en Tivoli Workload Scheduler for z/OS, debe especificar las cabeceras de informes en formato DBCS. JRUNHISTORY(YES|NO, CONTINUE|STOP) El parámetro JRUNHISTORY contiene dos valores de palabra clave: v El primer valor de la palabra clave define si el proceso de planificación diaria hace una copia de seguridad del plan actual en conjuntos de datos Generation Data Group (GDG). Especifique YES para solicitar la copia de seguridad, la cual es necesaria para llenar las tablas DB2 de historial usadas por la opción de generación de informes de Tivoli Dynamic Workload Console. Use el valor predeterminado NO para obviar la copia de seguridad. v El segundo valor de la palabra clave se ignora si especifica NO como primer valor de la palabra clave. Define si el trabajo de planificación diaria continúa cuando se produce un error durante el proceso de creación de copia de seguridad: CONTINUE El trabajo por lotes del plan diario continúa y se emite un mensaje de aviso. Las apariciones eliminadas del plan actual no se archivan. STOP El trabajo por lotes del plan diario fracasa. Es el valor predeterminado. | KEEPCOMPDEPS(NO|YES) | | | | | | | | | Esta palabra clave determina la permanencia de dependencias externas en una operación completada que pertenece a apariciones que aún están activas cuando se envía un trabajo de plan diario (ampliación o nueva planificación). Al ejecutar un plan, una ampliación o una nueva planificación utilizando este parámetro, puede mantener las dependencias entre dos operaciones que pertenezcan a distintas apariciones si ha terminado la operación predecesora. Normalmente, la dependencia se elimina después de la ejecución de un plan de trabajo, aun cuando la operación finalizada aún esté en el plan porque pertenece a una aparición activa. | | | | | | Ejemplo: supongamos que tiene la Aparición A con la Operación1 y la Operación2, y la Aparición B con la Operación1 y la Operación2, siendo la Operación1, en ambas apariciones, la predecesora de la Operación2, y siendo la Operación1 (Aparición A) además una predecesora de la Operación2 (Aparición B), lo que de ese modo crea una dependencia externa. Si la Operación1 (Aparición A) finaliza y la Operación2 (Aparición A) tiene un error, Capítulo 1. Definición de sentencias de inicialización 31 BATCHOPT | | | | | | | la Aparición A también tendrá el estado de error. Supongamos además que la Operación1 (Aparición B) está esperando una dependencia de tiempo. Si ahora ejecuta un trabajo de planificación diaria, ambas apariciones permanecen en el nuevo plan, pero la dependencia externa se elimina porque la predecesora (Operación1 - Aparición A) ha finalizado. Utilizando la palabra clave KEEPCOMPDEPS establecida en YES, la dependencia se mantiene en el nuevo plan. | Los valores válidos son: | | | NO El valor predeterminado. Cuando se amplía el plan, se eliminan las dependencias externas en una operación completada, incluso si la aparición sigue activa. | | | YES Cuando el plan se amplía, las dependencias externas siguen definidas en la operación. Esto facilita una operación de nueva ejecución porque no es necesario volver a definir la dependencia. LOGID(identificador en el conjunto de datos del registro de seguimiento|01) Una identificación situada en todos los registros del registro de seguimiento (EQQTROUT). La longitud es de 2 caracteres.Los valores válidos están en el rango numérico de 01 a 99. Si ha especificado el conjunto de datos EQQTROUT en el JCL de la planificación diaria, el conjunto de datos de archivado de seguimiento de trabajos (EQQJTARC) se copia a EQQTROUT. Las palabras claves NCPTROUT OCPTROUT especifican si los registros de plan actual también se copian. Si hay más de un controlador activo y se usa el mismo conjunto de datos EQQTROUT para recoger información de seguimiento de trabajos, puede usarse LOGID para diferenciar entre los registros de los distintos controladores. LTPDEPRES(NO|YES) Esta palabra clave es usada por el trabajo por lotes que amplia el plan a largo plazo. Especifique YES si los cambios a las bases de datos de Tivoli Workload Scheduler for z/OS deben reflejarse en la parte ampliada del LTP y la parte existente del plan. La parte existente del LTP es desde la hora del fin del plan actual hasta el fin del LTP. Especifique NO si la parte ampliada del LTP debe reflejar cambios a las bases de datos. La parte existente del LTP no cambiará cuando el trabajo por lotes sea ejecutado para ampliar el LTP. Una aparición del LTP que ha sido modificada mediante los diálogos o la interfaz de programa (PIF) no se ve afectada por los cambios hechos a las bases de datos, ni siquiera si se especifica LTPDEPRES(YES). LTPDEPRES no afecta a la eliminación de apariciones terminadas desde el LTP. Siempre que se ejecute un trabajo por lotes de modificación o de ampliación, todas las apariciones terminadas, cuyo comienzo planificado es anterior al día en el que existe la aparición no terminada más cercana, son eliminadas del LTP. Para obtener más información sobre el plan a largo plazo, consulte Managing the Workload MAXHISTORYROWS(número de filas|5000 Esta palabra clave, si se especifica con un valor distinto de cero, le indica a Tivoli Workload Scheduler for z/OS el número máximo de filas que se pueden recuperar de DB2 utilizando el mandato HIST. El valor predeterminado es 5000. El valor máximo es 999999. Si indica 0, todas las filas se recuperan sin limitaciones. 32 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste BATCHOPT Por ejemplo, indicando 1000 se establece 1000 como número máximo de filas que puede recuperar el procesamiento del mandato HIST. Si se recuperan menos de 1000 filas, éstas se muestran en el panel solicitante. Si se recuperan más de 1000 filas, se interrumpe el procesamiento del mandato HIST, se emite un mensaje de error y no se muestran datos en el panel solicitante. Para reducir la cantidad de datos que recuperar, establezca los criterios de filtrado adecuados. MAXOCCNUM(nnnnnnn|32767) Tivoli Workload Scheduler for z/OS mantiene un límite superior en el número de apariciones del plan actual. Cuando se supera este límite durante la ampliación del plan o durante su creación, el programa de lotes de planificación diaria falla y no se crea un nuevo plan. Si se omite la palabra clave, el límite es de 32767 apariciones. Es aconsejable no establecer el parámetro a un número mayor que el requerido por las necesidades de carga de trabajo reales debido a la sobrecarga aumentada que se produce. Las apariciones que vienen del plan anterior no se ven afectadas. NCPTROUT(NO|YES) Esta palabra clave define si Tivoli Workload Scheduler for z/OS debe copiar los registros del plan actual nuevo al conjunto de datos al que se hace referencia en el ddname de EQQTROUT en el proceso de planificación diario. Cuando se especifica NO, no se crearán los registros del registro de seguimiento para los registros de operación de la estación de trabajo y apariciones actualizados por el proceso de planificación diario cuando se crea un plan actual nuevo. El valor predeterminado, YES, provoca la creación de registros de seguimiento para los registros del plan actual nuevo correspondiente. OCPTROUT(YES|CMP|NO) Esta palabra clave define si Tivoli Workload Scheduler for z/OS debe copiar los registros del plan actual viejo al conjunto de datos al que se hace referencia en el ddname de EQQTROUT en el proceso de planificación diario. Cuando se especifica YES, se crean registros del registro de seguimiento para tipos de registros del plan actual 01, 02, 03 y 04. Los registros de tipo 03 llevados al plan actual nuevo para realizar informes y para apariciones predecesoras pendientes no se copian al archivo EQQTROUT porque estos registros serán copiados en un plan diario posterior. Cuando se especifica CMP, se copia el registro de tipo 03 del plan actual, al igual que lo hacen los registros de tipo 01 y tipo 04. El valor predeterminado, NO, define que Tivoli Workload Scheduler for z/OS no debe copiar registros desde el plan actual viejo a EQQTROUT durante el proceso de planificación diario. OPERDALL(Y|N) Este parámetro es usado por los trabajos por lotes de planificación a largo plazo al determinar la fecha límite para una operación que tiene un desplazamiento de día de fecha límite superior a cero en relación a la fecha de comienzo planificado de la aplicación. Y significa que Tivoli Workload Scheduler for z/OS tiene en cuenta todos los días (laborables y festivos) al determinar la fecha límite de la operación. N significa que sólo se tienen en cuenta los días laborables. Un día es considerado laborable o festivo según el calendario especificado en la descripción de la aplicación. Si no se especifica un calendario, se usa el calendario predeterminado. Capítulo 1. Definición de sentencias de inicialización 33 BATCHOPT Nota: OPERDALL no afecta a las horas límite de las apariciones. OPERHISTORY(YES|NO) Esta palabra clave es necesaria para la función de historial. Especifica que Tivoli Workload Scheduler for z/OS almacenará información de las operaciones terminadas en la base de datos DB2. Si especifica YES, también debe especificar la palabra clave DB2SYSTEM. Si especifica NO u omite la palabra clave, pero especifica palabras clave relacionadas (por ejemplo DB2SYSTEM, CONTROLLERTOKEN, DB2AVAIL o RETAINOPER)se emite un mensaje de aviso para informarle de que la función de historial no está activa (y por lo tanto, que no se han almacenado las apariciones terminadas en DB2). OPERIALL(Y|N) Este parámetro es usado por los trabajos por lotes de planificación a largo plazo al determinar la fecha de comienzo planificado para una operación que tiene un desplazamiento de día de comienzo planificado superior a cero en relación an la fecha de comienzo planificado de la aplicación. Y significa que Tivoli Workload Scheduler for z/OS tiene en cuenta todos los días (laborables y festivos) al determinar la fecha de comienzo planificado de la operación. N significa que sólo se tienen en cuenta los días laborables. Un día es considerado laborable o festivo según el calendario especificado en la descripción de la aplicación. Si no se especifica un calendario, se usa el calendario predeterminado. Nota: OPERIALL no afecta al comienzo planificado de las apariciones. PAGESIZE(tamaño de página para informes|55) Define el número de líneas por página en informes generador por Tivoli Workload Scheduler for z/OS. Puede especificar un valor numérico entre 30 y 500. PLANHOUR(inicio de período de planificación|6) Define la hora del día, en horas, en la que se inicia el período de planificación diaria. Este valor debe ser igual al valor especificado para PLANSTART en la sentencia JTOPTS. PREDWS(nombre de estación de trabajo predecesora predeterminada) Define un nombre de estación de trabajo predecesora predeterminada usada por la planificación diario para crear una dependencia externa cuando no puede encontrarse una operación predecesora específica. Esto puede ocurrir, por ejemplo, si se ha eliminado una operación o se ha cambiado el nombre de una estación de trabajo. El número más alto de operación de la aparición predecesora con un nombre de estación de trabajo que coincida con la definición PREDWS queda configurada como la predecesora. Si no se especifica PREDWS o si no hay coincidencia en el nombre de estación de trabajo, se usa el punto final de la aparición predecesora para establecer la dependencia. Si la aparición predecesora contiene varios puntos finales, se usa el punto final con el número de operación más alto.La planificación diario genera un mensaje de aviso para identificar las apariciones involucradas en la dependencia. El nombre de la estación de trabajo puede especificarse de modo genérico. PREVRES(NO|YES) Define si Tivoli Workload Scheduler for z/OS debe mantener los datos y 34 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste BATCHOPT producir informes de las 24 horas anteriores cuando se ejecuta un trabajo de planificación diaria. El valor predeterminado es producir informes para el período de planificiación anterior. RCLEANUP (YES NO) El valor RCLEANUP debe coincidir con el valor RCLEANUP en el OPCOPTS del controlador. Especifica si el lote DP debe crear registros CP que contengan la lista operinfo asociada a la aparición terminada. El controlador suprime después esta operinfo cuando se ha completado la rotación, si se especifica RCLEANUP(YES) en el OPCOPTS del controlador. | | | | | | | | | RETAINBIND(días|7) Cuando se ha enlazado una operación en el plan actual, el controlador envía notificaciones con el resultado enlazado y con el estado del trabajo enlazado con el motor que ha solicitado la vinculación. En el controlador, la solicitud del enlace se almacena en un registro de solicitudes de enlaces hasta que se notifica el último cambio de estado. Si no se puede enviar una notificación, la palabra clave RETAINBIND especifica cuántos días se va a guardar la solicitud de enlace cuando ya no se incluya la instancia del trabajo enlazado en el plan actual. El valor predeterminado es 7. RETAINOPER(días|0) Esta palabra clave se usa para la función de historial. Especifica cuántos días debe mantenerse una operación en la base de datos del historial. El valor predeterminado es cero. Significa que antes de que Tivoli Workload Scheduler for z/OS introduzca una aparición nueva en una tabla DB2, suprime todas las apariciones que tengan el mismo identificador de aplicación y que pertenezcan a versiones anteriores almacenadas después de haberse terminado una ampliación de plan actual o una operación de nueva planificación. Si especifica un valor distinto de cero, Tivoli Workload Scheduler for z/OS depura que es anterior a ese número de días. Así puede mantener más de una aparición de cada operación. Si especifica OPERHISTORY(NO) u omite la palabra clave OPERHISTORY, se ignora la palabra clave RETAINOPER. SUBSYS(nombre de subsistema|OPCA) Identifica el nombre del subsistema del controlador para el que se ejecuta el trabajo por lotes. Los trabajos por lotes de Tivoli Workload Scheduler for z/OS, por ejemplo planificación diaria o planificación a largo plazo, deben ejecutarse en el mismo sistema que el controlador si no se usa GRS (serialización de recursos global). Si su instalación usa GRS, los trabajos por lotes y el controlador deben ejecutarse en sistemas del mismo complejo GRS. SUCCWS(nombre de estación de trabajo sucesora) Define un nombre de estación de trabajo usada por la planificación diario para crear una dependencia externa cuando no puede encontrarse una operación sucesora específica. Esto puede ocurrir, por ejemplo, si se ha eliminado una operación o se ha cambiado el nombre de una estación de trabajo. El número más bajo de operación de la aparición sucesora con un nombre de estación de trabajo que coincida con la definición SUCCWS queda configurada como la sucesora. Si no se especifica SUCCWS o si no hay coincidencia en el nombre de estación de trabajo, se usa el punto final de la aparición sucesora para establecer la dependencia. Si la aparición sucesora contiene varios puntos finales, se usa el Capítulo 1. Definición de sentencias de inicialización 35 BATCHOPT punto final con el número de operación más bajo.El programa de planificación diario genera un mensaje de aviso para identificar las apariciones involucradas en la dependencia. El nombre de la estación de trabajo puede especificarse de modo genérico. TPLGYPRM (nombre de miembro|TPLGPARM) Especifique esta palabra clave su desea activar la característica de planificación global con capacidades de tolerancia a errores en el plan diario. El nombre de miembro especificado es un miembro de la PARMLIB en la que las opciones globales con tolerancia a errores son definidas por la sentencia TOPOLOGY. VALEACTION(END|WARN|ABEND) Define qué acción debe realizar un programa por lotes de planificación diaria cuando su código de validación detecta una inconsistencia en los datos. Especifique ABEND si debe producirse una terminación anómala. ABEND es el valor predeterminado. El trabajo de planificación diaria finaliza con el código de error S0C1, y no se crea un plan actual nuevo. La información de error se graba en el conjunto de datos de diagnóstico EQQDUMP. Los caracteres VALExxxx siguen al código de operación no válido (X'0000') e identifican el módulo donde se produjo el error. El vuelco de sistema producido en el momento de la terminación anómala será necesario si debe informarse del error como un defecto del programa. Especifique END si debe finalizar el trabajo de planificación diaria. La información de error se graba en el conjunto de datos de diagnóstico EQQDUMP. No se crea un plan actual nuevo. Especifique WARN si el trabajo de planificación diaria, cuando sea posible, debe omitir errores detectados. Los errores se describen en mensajes grabados en el registro de mensajes y en la información de diagnóstico grabada en EQQDUMP. Si los errores pueden ser omitidos, se crea un plan actual nuevo. Compruebe el plan actual lo antes posible porque puede contener errores. Por ejemplo, una dependencia puede no haber sido resuelta. Ejemplos BATCHOPT SUBSYS(OPCB) 1 CALENDAR(NSW) 2 SUCCWS(CPU*) 3 PREDWS(CPU*) 4 DATEFORM(’YY-MM-DD’) 5 HDRS(’NÚMERO DE CABECERA 1’, 6 ’CABECERA 2 ’, ’ESTA ES LA LÍNEA DE LA TERCERA CABECERA’) En este ejemplo de una sentencia BATCHOPT: 36 1 El trabajo por lotes se ejecuta contra el subsistema OPCB. 2 Se usa el calendario predeterminado NSW. 3 Cualquier operación ejecutada en una estación de trabajo cuyo nombre comienza con los caracteres CPU es elegible cono sucesora predeterminada. 4 Cualquier operación ejecutada en una estación de trabajo cuyo nombre comienza con los caracteres CPU es elegible cono predecesora predeterminada. IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste BATCHOPT 5 6 El formato es año, mes y día, separados por un guión (-). Las cabeceras de informes tienen este texto: CABECERA NÚMERO 1 CABECERA 2 ESTA ES LA LÍNEA DE LA TERCERA CABECERA Capítulo 1. Definición de sentencias de inicialización 37 CPUREC CPUREC Propósito La sentencia CPUREC inicia una definición (CPU) de estación de trabajo de Tivoli Workload Scheduler. Debe especificar una CPUREC para cada estación de trabajo de Tivoli Workload Scheduler que desee añadir a la red global con capacidades de tolerancia a errores, con la excepción del controlador que actúa como gestor de dominio maestro de la red. CPUREC se define en el miembro de la biblioteca EQQPARM tal y como se especifica con el parámetro TPLGYMEM de la sentencia TOPOLOGY. Para obtener una descripción detallada de esta sentencia, consulte Tivoli Workload Scheduler for z/OS: Planificación global con capacidades de tolerancia a errores. 38 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste DBCSOPTS DBCSOPTS Propósito La sentencia DBCSOPTS define las opciones de formato para la opción de idioma japonés de Tivoli Workload Scheduler for z/OS. Puede especificar esta sentencia para un controlador o controlador en reposo. Para el entorno en línea, DBCSOPTS debe aparecer en el mismo miembro de la biblioteca EQQPARM que la sentencia. Para el entorno por lotes, debe aparecer en el mismo miembro de la biblioteca de parámetro que la sentencia BATCHOPT. Importante: Use la misma definición de sentencia DBCSOPT para la inicialización en línea y por lotes. Formato DBCSOPTS APPLID( EBCDIC DBCS ) OWNERID( EBCDIC DBCS ) SORTORDER( KS KR ) Parámetros APPLID(DBCS|EBCDIC) Define el formato en el que el campo de identificador de aplicación y el campo de identificador de definición serán almacenados en la base de datos de Tivoli Workload Scheduler for z/OS. Especifique DBCS si estos campos deben almacenarse en formato DBCS con delimitadores. Especifique EBCDIC si estos campos deben almacenarse en formato EBCDIC con delimitadores. Nota: No puede usar el diálogo diálogo Descripción de trabajo si especifica DBCS porque no es posible especificar un nombre de trabajo en formato DBCS. OWNERID(DBCS|EBCDIC) Define el formato en el que el campo de identificador de propietario será almacenado en la base de datos de Tivoli Workload Scheduler for z/OS. Especifique DBCS si el identificador de propietario debe almacenarse en formato DBCS con delimitadores. Especifique EBCDIC si debe almacenarse en formato EBCDIC. SORTORDER(KR|KS) Define el orden de DBCS que debe usarse al ordenar campos que contengan datos DBCS. Puede especificarse uno de estos tipos: KR Número de trazos radicales básicos de los kanji KS Número de trazos totales básicos de los kanji Capítulo 1. Definición de sentencias de inicialización 39 DBCSOPTS Ejemplos DBCSOPTS APPLID(DBCS) SORTORDER(KR) 1 2 En este ejemplo de una sentencia DBCSOPTS: 40 1 Los identificadores de aplicación y los identificadores de definición de grupo se almacenarán en formato DBCS con delimitadores. 2 Los campos DBCS se ordenarán según el número de trazos radicales básicos de los kanji en los informes de Tivoli Workload Scheduler for z/OS. IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste DBOPT DBOPT Propósito Use esta sentencia para dar soporte a la generación de informes de Tivoli Dynamic Workload Console. Ofrece la información requerida para conectarse a la base de datos y al almacén de datos. La información es usada por el programa Java que llena las tablas de historial y por el servidor que ofrece la información de URL al proceso de Tivoli Dynamic Workload Console. Formato DBOPT CLEANUPPOLICY( 10 días ) 150 nnn LONGDURPOLICY( ) SMOOTHPOLICY( porcentaje ) DBURL( url ) DBUSER( id de usuario ) DBPSW( contraseña ) TIMEZONE( serie_huso horario ) CODEPAGE( IBM – 037 página de códigos del sistema principal ) TRACELEVEL( 0 nivel WRKDIR( directorio de trabajo ) ) Parámetros CLEANUPPOLICY (días|10) El número de días que se almacenan los datos de ejecución histórica en la base de datos. Los datos más antiguos que los días especificados se eliminan. El valor predeterminado es 10 días. LONGDURPOLICY (nnn|150) La política usada para decidir si un trabajo es de larga duración, basándose en la fórmula: AD >= (ED * LDP / 100) donde las variables indican lo siguiente: AD La duración real. ED La duración estimada. LPD La política de larga duración. Especifique un valor entre 100 y 999. El valor predeterminado es 150. SMOOTHPOLICY (porcentaje) La política usada para calcular la duración media de un trabajo. Establece el factor de ponderación que favorece la ejecución del trabajo más reciente al calcular la duración media de un trabajo. Se expresa como porcentaje. Por ejemplo, una valor de 40 aplica un factor de ponderación del 40% a la ejecución del trabajo más reciente, y un 60% a la media existente. Capítulo 1. Definición de sentencias de inicialización 41 DBOPT Si no establece este parámetro, no se usa la corrección y la duración media se calcula como el tiempo transcurrido total dividido entre el número de ejecuciones satisfactorias. DBURL (url) Información sobre URL, en el siguiente formato: jdbc:db2://servidor:puerto/basededatos donde las variables indican lo siguiente: servidor La dirección TCP/IP o nombre de host del sistema donde reside la base de datos. puerto El número de puerto SQL usado por el servidor DB2. basededatos El nombre de la base de datos de destino. Este parámetro es necesario y no tiene un valor predeterminado. DBUSER (id de usuario) El identificador de usuario para acceder a la base de datos. Este parámetro es necesario y no tiene un valor predeterminado. DBPSW (contraseña) La contraseña asociada al usuario establecido en DBUSER. Para evitar dejar la contraseña como texto sin formato, puede cifrarla. Para obtener detalles sobre cómo cifrar la contraseña, consulte Gestión de la carga de trabajo. La contraseña puede contener hasta 15 caracteres. Este límite garantiza que la contraseña seguirá cabiendo en una línea después de cifrarla. Este parámetro es necesario y no tiene un valor predeterminado. TIMEZONE (serie_huso horario) El huso horario local del sistema z/OS donde se ejecuta , por ejemplo TIMEZONE(’Europe/Rome’). Es el formato utilizado en los archivos zoneinfo estándar en el lado distribuido. . No especifique el huso horario con formato de tres letras porque provocaría un huso horario incorrecto desde las API Java durante el horario de verano. Este parámetro es necesario y no tiene un valor predeterminado. CODEPAGE (página de códigos del sistema principal|IBM–037) El nombre de la página de códigos del sistema principal usado por el proceso de archivado. Puede proporcionar el valor IBM–nnn, donde nnn es la página de códigos EBCDIC. El valor predeterminado, IBM–037, define la página de códigos EBCDIC para inglés americano, portugués y francés de Canadá. A continuación se muestra una lista de las páginas de códigos EBCDIC: IBM–939 Japón, extendido IBM–937 Taiwán IBM–935 China IBM–933 Corea IBM–975 Grecia IBM–971 Islandia IBM–970 Latín 2 IBM–838 Tai IBM–500 Internacional IBM–424 Israel 42 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste DBOPT IBM–297 IBM–285 IBM–284 IBM–280 IBM–278 IBM–277 IBM–274 IBM–273 IBM–1388 IBM–1122 IBM–1112 IBM–1047 IBM–1026 IBM–1025 Francia Reino Unido España - América latina Italia Suecia - Finlandia Dinamarca - Noruega Bélgica Alemania China Estonia Báltico Sistemas abiertos Latín 5 (Turquía) Cirílico A continuación se muestra una lista de las páginas de códigos EBCDIC que aceptan EURO: IBM–1140 Finlandia, Suecia IBM–1141 Austria, Alemania IBM–1142 Dinamarca, Noruega IBM–1143 EE.UU. IBM–1144 Italia IBM–1145 España , América latina IBM–1146 Reino Unido IBM–1147 Francia IBM–1148 Bélgica, Suiza TRACELEVEL (nivel|0) Nivel de rastreo para registro cronológico y rastreo interno. Los valores posibles son los siguientes: 0 Para recibir sólo mensajes de error. 1 Para recibir mensajes de error y de aviso. 2 Para recibir mensajes de error, de aviso e informativos. 3 Indica el nivel ajustado para recibir los mensajes más importantes con el volumen más bajo. 4 Indica el nivel algo más ajustado para activar los rastreos de entrada y salida. 5 Indica el nivel más ajustado para recibir el rastreo más detallado. El valor predeterminado es 0. WRKDIR (directorio de trabajo) La ruta completa del directorio de trabajo para el proceso de archivo. Cada subsistema debe tener su propio directorio de trabajo. Puede usar el mismo directorio de trabajo usado en la planificación global con capacidades de tolerancia a errores. Este parámetro es necesario y no tiene un valor predeterminado. Ejecute EQQPCS08 para personalizar el contenido del directorio de trabajo. Este parámetro es necesario y no tiene un valor predeterminado. Capítulo 1. Definición de sentencias de inicialización 43 DOMREC DOMREC Propósito La sentencia DOMREC comienza una definición de dominio. Debe especificar una DOMREC para cada dominio de Tivoli Workload Scheduler que vaya a añadir en la red global con capacidades de tolerancia a errores, con la excepción del dominio maestro. El nombre de dominio usado para el dominio maestro es MASTERDM. El dominio maestro lo forman el controlador, que actúa como el gestor de dominio maestro, y cualquier agente tolerante a errores y estándar que estén adjuntados directamente a él. DOMREC se define en el miembro de la biblioteca EQQPARM tal y como se especifica con la palabra clave TPLGYMEM en la sentencia TOPOLOGY. Para obtener una descripción detallada de esta sentencia, consulte Tivoli Workload Scheduler for z/OS: Planificación global con capacidades de tolerancia a errores. 44 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste DSTOPTS DSTOPTS Propósito La sentencia DSTOPTS define las opciones de tiempo de ejecución para el almacén de datos. DSTOPTS se define en el miembro de la biblioteca EQQPARM tal y como se especifica en la sentencia DD del JCL. Formato DSTOPTS 0 tiempo de intervalo CINTERVAL( ) CLNPARM( EQQCLNPA nombre de miembro ) DELAYTIME( 1 nn ) DSTLUNAM(Nombre de unidad lógica) CTLLUNAM(Nombre de unidad lógica) DSTGROUP(NombreGrupoXCF) CTLMEM(NombreMemXCF) DSTMEM(NombreMemXCFM) CTLHOSTNAME( nombrehost )CTLPORTNUMBER(puerto TCPIP) dirección IP FAILDEST( FAILDEST destino ) JOBNAME valor HDRJOBNAME( ) HDRSTEPNAME( STEPNAME valor ) PROCSTEP valor HDRPROCNAME( ) HDRJOBLENGTH( 13,21 longitud ) HDRSTEPLENGTH( 22,30 longitud ) HDRPROCLENGTH( 31,39 longitud HOSTCON( ) ) HDRSTEPNOLENGTH( 120 longitud ) SNA XCF TCP MAXSTOL( 0 nnnnn ) MAXMVSPAGES( 4096 nnnn ) MAXSYSL( 4096 nnnn ) MAXUNPAGES( 0 nnnnn ) NWRITER( 1 nn ) QTIMEOUT( 15 nnnnn ) RETRYCOUNTER( 1 nn ) SMSMODDELETE( NO YESD ) STORESTRUCMETHOD( IMMEDIATE DELAYED ) STOUNSD( NO YES ) SYSDEST( OPC destino ) WINTERVAL( 30 nnnn ) Capítulo 1. Definición de sentencias de inicialización 45 DSTOPTS Parámetros CINTERVAL(tiempo de intervalo|0) Define el tiempo de intervalo de activación de la tarea de limpieza, expresado en minutos. Los valores válidos están comprendidos entre 0 y 1440. 0 es el valor predeterminado y significa que la subtarea de limpieza (CleanUp) del almacén de datos se inicia con la inicialización del almacén de datos, pero nunca se ejecuta. CLNPARM(nombre de miembro|EQQCLNPA) Define el nombre de miembro del parámetro que contendrá el criterio de la tarea CleanUp. El valor predeterminado es EQQCLNPA. Este parámetro sólo es significativo si CINTERVAL es mayor de 0; sin embargo, es necesario en el inicio del almacén de datos porque el almacén de datos carga la información contenida en el miembro sólo en el momento del inicio e, incluso si inicialmente se establece CINTERVAL(0), se puede modificar más tarde este valor con un mandato de operador. CTLLUNAM(Nombre de unidad lógica) Define el nombre de unidad lógica de la aplicación VTAM que identifica el controlador en la conexión SNA entre el controlador y el almacén de datos. Es obligatoria si se usa la conexión SNA entre el controlador y el almacén de datos, y debe ser igual que la especificada en la sentencia FLOPTS CTLLUNAM del controlador. CTLMEM(NombreMemXCF) Nombre de miembro XCF que identifica el controlador en la conexión XCF entre el controlador y el almacén de datos. Es obligatoria si se usa la conexión XCF y debe ser igual que la especificada en la sentencia FLOPTS CTLMEM del controlador. CTLHOSTNAME(nombrehost|dirección IP) El nombre de host o la dirección IP del controlador remoto. Los valores válidos son nombres completos de hasta 52 caracteres. CTLPORTNUMBER(puerto TCPIP|423) El número de puerto TCP/IP usado para comunicarse con el controlador remoto. Los valores válidos están comprendidos entre 0 y 65535. El valor predeterminado es 423. DELAYTIME(nn|1) Tiempo de retardo, expresado en minutos, usado para decidir cuándo desechar/almacenar salidas de sistema incompletas. Los valores válidos están comprendidos entre 0 y 1440. El valor predeterminado es 1. DSTGROUP(NombreGrupoXCF) Define el nombre de grupo XCF que identifica el almacén de datos en la conexión XCF con el controlador. Es obligatoria si se usa la conexión XCF. El grupo XCF definido para conectar el almacén de datos al controlador debe se distinto del definido en el grupo XCFOPTS para conectar el controlador al comprobador de seguimiento de z/OS. DSTLUNAM(Nombre de unidad lógica) Define el nombre de unidad lógica de la aplicación VTAM que identifica el almacén de datos en la conexión SNA entre el controlador y el almacén de datos. Es obligatoria si se usa la conexión SNA entre el controlador y el almacén de datos. 46 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste DSTOPTS DSTMEM(NombreMEMXCF) Nombre de miembro XCF que identifica el almacén de datos en la conexión XCF entre el controlador y el almacén de datos. Es obligatoria si se usa la conexión XCF. FAILDEST(destino|FAILDEST) Define un destino donde los trabajos que no pueden ser archivados volverán a ser puestos en la cola para poder examinarlos. HDRJOBNAME(valor|JOBNAME) Identificador de nombre de trabajo para STEPTABLE HEADER en la salida de sistema JESMSGLG. JOBNAME es el valor predeterminado usado por Tivoli Workload Scheduler for z/OS. Puede especificar cualquier otro valor de hasta ocho caracteres, según la personalización de salida de EQQACTR1. HDRSTEPNAME(valor|STEPNAME) Identificador de nombre de paso para STEPTABLE HEADER en la salida de sistema JESMSGLG. STEPNAME es el valor predeterminado usado por Tivoli Workload Scheduler for z/OS. Puede especificar cualquier otro valor de hasta ocho caracteres, según la personalización de salida de EQQACTR1. HDRPROCNAME(valor|PROCSTEP) Identificador del paso del proceso (procstep) para STEPTABLE HEADER en la salida de sistema JESMSGLG. PROCSTEP es el valor predeterminado usado por Tivoli Workload Scheduler for z/OS. Puede especificar cualquier otro valor de hasta ocho caracteres, según la personalización de salida de EQQACTR1. HDRJOBLENGTH(longitud|21) Posición de inicio del nombre de trabajo en STEPTABLE. Puede especificar cualquier otra longitud según la personalización de salida de EQQACTR1. No se incluye el carácter ASA. HDRSTEPLENGHTH(longitud|30) Posición de inicio de STEPNAME en STEPTABLE. El valor predeterminado es 30.Puede especificar cualquier otra longitud según la personalización de salida de EQQACTR1. No se incluye el carácter ASA. HDRPROCLENGTH(longitud|39) Posición de inicio de PROCNAME en STEPTABLE. El valor predeterminado es 39. Puede especificar cualquier otra longitud según la personalización de salida de EQQACTR1. No se incluye el carácter ASA. HDRSTEPNOLENGTH(longitud|120) Posición de inicio del nombre de trabajo en STEPTABLE. El valor predeterminado es 120.Puede especificar cualquier otra longitud según la personalización de salida de EQQACTR1. No se incluye el carácter ASA. HOSTCON(SNA|XCF|TCP) Define el tipo de conexión usada al transmitir datos al controlador. Es obligatoria (no existe valor predeterminado). MAXSTOL(nnnnn|0) Define el número máximo de salidas de sistema de usuario (sin líneas de salida de sistema) que el almacén de datos puede almacenar para un solo trabajo. Los valores válidos están comprendidos entre 0 y 10000. Si se especifica 0 no se almacenan salidas de sistema de usuario. El valor predeterminado es 0. NO es necesaria información de la salida de sistema de usuario para el proceso de reinicio y limpieza. Sólo debe especificarse un valor distinto de cero si es necesario para ver los datos de salida de sistema de usuario al recuperar un registro de trabajo Capítulo 1. Definición de sentencias de inicialización 47 DSTOPTS usando el mandato de la fila "L" (por ejemplo si una salida de sistema de usuario contiene información necesitada por las operaciones para determinar cómo devolver un trabajo). Especificar un valor distinto de cero podría hacer que se grabara una gran cantidad de datos en los archivos UDF del almacén de datos, así que es posible que necesite aumentar el tamaño o el número de los archivos UDF. Nota: El parámetro "USER SYSOUT" de Detalles de operación de reinicio y limpieza para una operación (panel TWS EQQAMRL) debe establecerse a Y, de lo contrario la salida de sistema de usuario no se grabará en el almacén de datos para esa operación. MAXMVSPAGES(nnnn|4096) Define el tamaño máximo (en número de páginas) permitido para que el proceso gestione la parte MVS de un registro de trabajos (JESJCLIN, JESJCL, JESMSGLG, JESYSMSG). Si la parte MVS del registro de trabajos supera este valor, el registro de trabajos no se almacena, el procesamiento del analizador no se realiza y el registro de trabajos se vuelve a colocar en cola en el destino de anomalías, tal como lo establezca la palabra clave FAILDEST. Por ejemplo, si Tot_Rec es el número de registros del registro de trabajos, el número de páginas para el registro de trabajos se calcula como (Tot_Rec*135)/4096. Los valores válidos están comprendidos entre 0 y 4096. El valor predeterminado es 4096. MAXSYSL(nnnn|0) Define el número máximo de salidas de sistema de usuario (sin líneas de salida de sistema) que el almacén de datos puede devolver al controlador. Los valores válidos están comprendidos entre 0 y 10000. Si se especifica 0 no se devuelve salida de sistema de usuario al controlador. El valor predeterminado es 0. NO es necesaria información de la salida de sistema de usuario para el proceso de reinicio y limpieza. Sólo debe especificarse un valor distinto de cero si es necesario para ver los datos de salida de sistema de usuario al recuperar un registro de trabajo usando el mandato de la fila "L" (por ejemplo si una salida de sistema de usuario contiene información necesitada por las operaciones para determinar cómo devolver un trabajo). Especificar un valor distinto de cero podría hacer que se grabara una gran cantidad de datos en los archivos UDF del almacén de datos, así que es posible que necesite aumentar el tamaño o el número de los archivos UDF. MAXUNPAGES(nnnn|4096) Define el tamaño máximo (en cuanto a número de páginas) permitido para almacenar un registro de trabajo. Cuando el tamaño de un registro de trabajo es superior a este valor, el registro de trabajo no se almacena. Por su parte, los datos estructurados se almacenan independientemente del STORESTRUCMETHOD especificado. Si Tot_Rec es el número de los registros de un registro de trabajo, el número de páginas para un registro de trabajo es (Tot_Rec*135) / 4096. Los valores válidos están comprendidos entre 0 y 4096. El valor predeterminado es 4096. Si se establece MAXUNPAGES demasiado baja, el almacén de datos usa más CPU debido a que se analizan más registros de trabajo. Si se establece MAXUNPAGES demasiado alta, es posible que se tarde mucho tiempo en grabar los registros de trabajo grandes. 48 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste DSTOPTS NWRITER(nn|1) Define el número de tareas de grabador que deben ser activados por el almacén de datos. Los valores válidos están comprendidos entre 1 y 16. El valor predeterminado es 1. El número de las tareas de grabador debe ser inferior a o igual que el número de archivos de VSAM del almacén de datos. Para obtener detalles, consulte el Capítulo 8, “Utilización del almacén de datos”, en la página 327. RETRYCOUNTER(nn|1) Define el número máximo de veces que el almacén de datos reintenta archivar trabajos dentro del tiempo de retardo especificado antes de suprimirlos de la cola reservada. Este número corresponde al número máximo de mensajes 'archivado en progreso' emitidos antes de suprimir el trabajo de la cola reservada y de volverlo a poner en la cola del destino de trabajo (el especificado con el parámetro FAILDEST). Debido a que los trabajos problemáticos pueden hacer disminuir el rendimiento del almacén de datos, es aconsejable usar valore bajos o el valor predeterminado (1). SMSMODDELTE(YES|NO) Este parámetro sólo es válido para las acciones de limpieza que realiza EQQCLEAN para conjuntos de datos SMS asignados con DISP=(MOD, CATLG, CATLG) en la ejecución anterior del trabajo. Si el conjunto de datos SMS existía antes de la ejecución anterior del trabajo, no se elimina, independientemente del valor establecido en este parámetro. Especifique NO para evitar que EQQCLEAN elimine los conjuntos de datos SMS creados en la ejecución anterior del trabajo. Especifique YES para hacer que EQQCLEAN elimine los conjuntos de datos y se reinicie. El valor predeterminado es NO. QTIMEOUT(nnnnn|15) Define el tiempo máximo que el almacén e datos puede tardar en tramitar una solicitud de recuperación de registro de trabajo emitida por el controlador cuando la salida de sistema todavía no está almacenada en la base de datos VSAM porque el proceso de archivado de ese registro de trabajo está en progreso. Si caduca este tiempo QTIMEOUT y la solicitud no ha sido tramitada, se emite el mensaje EQQFSR5I. Después de este mensaje, no se vuelve a intentar obtener el registro de trabajo. Por lo tanto, debe emitir otra solicitud para recibir el registro de trabajo. Se expresa en segundos y los valores permitidos están comprendidos entre 1 y 10000. El valor predeterminado es 15. STORESTRUCMETHOD(DELAYED|IMMEDIATE) Define cuándo archivar los datos estructurados. Si especifica IMMEDIATE, el almacén de datos analiza y archiva inmediatamente los registros de trabajo encontrados en su destino reservado. Esto significa que los datos estructurados se generan siempre para todos los registros de trabajo manipulados por el almacén de datos. Si especifica DELAYED, el almacén de datos archiva inmediatamente los registros de trabajo encontrados en su destino reservado, pero analiza y archiva la información estructurada creada usando el registro de trabajo sin estructurar archivado anteriormente. Cuando se especifica DELAYED, los datos estructurados se almacenan incluso para registros de trabajo superiores al valor establecido para MAXUNPAGES o superiores a 4096 páginas, si no se especifica MAXUNPAGES. Capítulo 1. Definición de sentencias de inicialización 49 DSTOPTS STOUNSD(YES|NO) El valor predeterminado es NO. Seleccione YES para almacenar datos sin estructurar en la base de datos del almacén de datos y para habilitar la función de recuperación de trabajos para el registro de trabajo de z/OS. Nota: Si establece STORESTRUCMETHOD a DELAYED también debe establecer STOUNSD a YES. De este modo el método de archivado puede extraer los datos estructurados del registro de trabajo. SYSDEST(OPC|destino) Define el destino usado para capturar la salida de sistema desde el subsistema de entrada de trabajos. Debe ser igual al valor del parámetro RCLOPTS DSTDEST. WINTERVAL(nnnn|30) Define el intervalo máximo de tiempo que puede transcurrir antes de que el almacén de datos explore el destino reservado. Para explicar mejor cómo se usa este valor, recuerde que: v JESQUEUE es la tarea que lee el archivo de spool de JES para obtener los registros de trabajo que debe manejar el almacén de datos usando como criterio de filtro el "destino reservado" v Con esta lectura, JESQUEUE compila una lista de identificadores de trabajo (JOBID) para manejar (el número máximo de JOBID leídos desde el archivo de spool de JES cada vez es 3N+1 donde N es el número de tareas de grabador definidas) v Cuando se ha compilado esta lista enlazada, la tarea JESQUEUE la comprueba hasta que la vacían las tareas WRITERS v En este punto, antes de volver a crear la lista enlazada de nuevo, la tarea JESQUEUE espera el intervalo de tiempo especificado en WINTERVAL. Se expresa en segundos y los valores permitidos están comprendidos entre 0 y 3600. El valor predeterminado es 30. 50 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste DSTUTIL DSTUTIL Propósito La sentencia DSTUTIL define las acciones posibles de mantenimiento que pueden realizarse en la base de datos del almacén de datos, y normalmente son invocadas por un programa por lotes. Las acciones de limpieza de mantenimiento (DELUNSTR/DELSTRUC/DELBOTH) pueden ser realizadas mediante la tarea de limpieza del almacén de datos (si se especifica en el número identificado por la sentencia CLNPARM). Formato DELSTRUC DELUNSTR EXPSTRUC EXPUNSTR DELBOTH DDNAME( DDNAME(ddn) ddn1,ddn2 DDNAME(ddn) EXPBOTH ) IMPORT DDNAME( ddn1,ddn2 ) DDNAME(ddn) REPLACE (YES|NO) RECOVER (principal) SEARCH1(valor) SEARCH2(valor) SEARCH3(valor) SEARCH4(valor) SEARCH5(valor) SEARCH6(valor) SEARCH7(valor) SEARCH8(valor) SEARCH9(valor) SEARCH10(valor) REPLACE(YES|NO) Parámetros DELSTRUC|DELUNSTR|DELBOTH Define el criterio para suprimir la salida de sistema de la base de datos del almacén de datos. Es posible especificar si deben suprimirse datos estructurados (DELSTRUC) o sin estructurar DELUNSTR). Puede necesitar suprimir ambos tipos especificando DELBOTH. La palabra clave DDNAME, si está codificada, identifica el nombre de controlador de dispositivo de un conjunto de datos donde se copian los registros antes de suprimirlos de la base de datos. Cuando se codifica DELBOTH, hay que especificar dos DDnames, para los dos tipos distintos de datos: el primero es para los datos sin estructurar, y el segundo es para los datos estructurados). La copia en un conjunto de datos sólo está permitida en modalidad de proceso por lotes. La palabra clave SEARCHnn (donde nn puede ser un valor de entre 1 y 10) identifica los criterios seleccionados. La serie valor tiene el siguiente formato: CodeNameComparisonOperFieldName CodeName puede tener los siguientes valores: Capítulo 1. Definición de sentencias de inicialización 51 DSTUTIL JBNM JBDT JBTM JBID DSID STNM PSNM DDNA SYCL OLDR Nombre de trabajo Fecha Hora ID de trabajo ID de conjunto de datos Nombre de paso Nombre de paso de procedimiento Nombre de controlador de dispositivo Clase de SYSOUT Anterior a ComparisonOper puede tener los siguientes valores: EQ Igual NE Distinto GT Mayor que GE Mayor o igual LT Menor que LE Menor o igual LK Igual que UK Distinto de MM Mes, usado sólo con nombre de código OLDR DD Días, usado sólo con nombre de código OLDR HR Horas, usado sólo con nombre de código OLDR MN Minutos, usado sólo con nombre de código OLDR FieldName indica el campo donde se realiza la selección. Por ejemplo, puede ser un nombre de trabajo específico si se ha usado el nombre de código JBNM (JBNM EQ myjob hace que todos los registros de trabajo tengan el nombre de trabajo igual que el myjob que debe suprimirse. Para el operador LK, puede contener el comodín * o ?). Nota: Todas las fechas deben especificarse en formato aaaammddy. Por ejemplo, el 22 de julio de 2002 se codifica como 20020722. Todos los términos dentro de la clave SEARCHn son ANDs lógicos, por lo tanto deben ser verdaderos para seleccionar la salida de sistema de la operación. Los distintos criterios de búsqueda (SEARCH1 a SEARCH10) son ORs lógicos, por lo tanto al menos uno debe ser verdadero para ejecutar el comando. EXPSTRUC|EXPUNSTR|EXPBOTH Define el criterio para exportar los registros de salida de sistema de una base de datos del almacén de datos. Es posible especificar si deben exportarse datos estructurados (EXPSTRUC) o sin estructurar (EXPUNSTR). La palabra clave DDname es siempre necesaria e identifica el nombre de controlador de dispositivo de un conjunto de datos donde van a exportarse los registros. Puede que sea necesario exportar ambos tipos especificando EXPBOTH: en este caso, deben especificarse dos ddnames distintos como valores en la cláusula DDNAME. El primero es para los datos sin estructurar y el segundo es para los datos estructurados. Las palabras clave usadas en la misma cláusula tienen el mismo significado especificado para los parámetros DELSTRUC/DELUNSTR/DELBOTH. También se puede especificar el criterio de selección codificando la palabra clave SEARCHnn. 52 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste DSTUTIL IMPORT Define el criterio para importar registros de salida de sistema (almacenados previamente en un conjunto de datos secuencial) a la base de datos del almacén de datos. Las palabras clave tienen el mismo significado que las especificadas para los parámetros anteriores. Además, la palabra clave REPLACE especifica si deben sobrescribirse los registros de salida de sistema de la base de datos del almacén de datos que coinciden. El valor predeterminado es NO. Puede importarse un conjunto de datos cada vez (sólo puede codificarse un DDname). Si deben importarse datos estructurados y sin estructurar, debe codificarse dos veces el parámetro IMPORT para procesar por separado los archivos de exportación estructurados y sin estructurar. IMPORT puede ser usado por el programa de proceso por lotes sólo cuando no está funcionando el almacén de datos. También se puede especificar el criterio de selección codificando la palabra clave SEARCHnn. RECOVER(PRIMARY) Indica que el programa de proceso por lotes extrae un conjunto de datos de claves para todos los registros de salidas de sistema almacenados en la base de datos del almacén de datos, para habilitar la recuperación de un conjunto de datos de claves primarias corruptas. La sentencia EQQPKREC DD del JCL por lotes identifica el nombre del conjunto de datos extraídos. Puede ser usado por el programa de proceso por lotes sólo cuando no esté funcionando el almacén de datos. En este caso, no se puede usar la palabra clave SEARCHnn para especificar el criterio de selección porque no se acepta. Capítulo 1. Definición de sentencias de inicialización 53 ERDROPTS ERDROPTS Propósito La sentencia ERDROPTS define las opciones de tiempo de ejecución para una tarea de grabador de sucesos. Puede especificar esta sentencia para un comprobador de seguimiento, controlador, o controlador en reposo. Esta sentencia es necesaria si no se especifica ERDRTASK(0) en la sentencia OPCOPTS. ERDROPTS se define en el miembro de la biblioteca EQQPARM tal y como se especifica con el parámetro ERDRPARM de la sentencia OPCOPTS. Formato ERDROPTS ERSEQNO( número de secuencia del lector de sucesos ) ERWAIT( 10 límite de espera ) RELDDNAME( ddname del conjunto de datos de envío/liberación ) Parámetros ERSEQNO(número de secuencia del lector de sucesos) Define qué lector de sucesos se está iniciando. Este número debe estar entre 1 y 16 y define el ddname del conjunto de datos de sucesos de entrada. El ddname del conjunto de datos de sucesos de entrada correspondiente tiene el formato EQQEVDnn, donde nn es el número de secuencia del lector de sucesos especificado como número de 2 dígitos. Si el número de secuencia es inferior a 10, debe añadirse un cero delante. Por ejemplo, si se especifica ERSEQNO(1), el ddname debe ser EQQEVD01. Asegúrese de que este ddname esté en su procedimiento JCL. Nota: Puede iniciar sólo un lector de sucesos para cada conjunto de datos de sucesos de entrada. No debe especificar el mismo número parar ERSEQNO y el número de secuencia del grabador de sucesos (EWSEQNO) si ambas tareas están activas en el mismo sistema. ERWAIT(límite de espera|10) Define cuánto tiempo (en segundos) espera el lector de sucesos antes de volver a comprobar el conjunto de datos de sucesos de entrada después de que hayan sido leídos todos los registros de sucesos. Influirá en la velocidad a la que se actualiza la lista de preparados. RELDDNAME(ddname del conjunto de datos de envío/liberación) RELDDNAME se usa en una configuración DASD compartida, donde el sistema de destino usa la función mantener/liberar. Identifica el conjunto de datos de envío/liberación en los que el controlador graba mandatos de liberación. RELDDNAME es necesaria si los sucesos no se crean en el mismo sistema en el que se inicia el lector de sucesos. El ddname es el mismo nombre que se especifica en el campo de destino de la estación de trabajo y la palabra clave DASD de ROUTOPTS. 54 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste ERDROPTS Ejemplos ERDROPTS ERSEQNO(1) ERWAIT(5) 1 2 En este ejemplo de una sentencia ERDROPTS: 1 Se inicia el número del lector 1. 2 El lector esperará 5 segundos antes de volver a comprobar su conjunto de datos de sucesos de entrada. Capítulo 1. Definición de sentencias de inicialización 55 EWTROPTS EWTROPTS Propósito La sentencia EWTROPTS define las opciones de tiempo de ejecución para una tarea de grabador de sucesos. EWTROPTS es necesaria cuando se especifica OPCOPTS EWTRTASK(YES). Esta sentencia es usada por un comprobador de seguimiento. EWTROPTS se define en el miembro de la biblioteca EQQPARM tal y como se especifica con el parámetro EWTRPARM de la sentencia OPCOPTS. Formato (1) EWTROPTS EWSEQNO( número de secuencia del conjunto de datos ) (2) EWWAIT 10 límite de espera ( ) HOLDJOB( NO USER YES ) END NO ALL PRINTEVENTS( ) LAST HIGHEST RETCODE( ) SDEPFILTER( startpos,stringvalue ) (2) SKIPDATE ( 860101 aammdd ) (2) SKIPTIME 0000 hhmm ( ) STEPEVENTS( ABEND ALL NZERO ) SUREL( NO YES ) Notas: 56 1 Si el controlador de Tivoli Workload Scheduler for z/OS tiene que realizar proceso de NOERROR en todos los comprobadores de seguimiento conectados a ese controlador RETCODE debe establecerse a HIGHEST y STEPEVENTS debe establecerse a ALL o NZERO. 2 Tivoli Workload Scheduler for z/OS usa los valores EWWAIT, SKIPDATE y SKIPTIME sólo si se especifica SUREL(YES). IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste EWTROPTS Parámetros EWSEQNO(número de secuencia del conjunto de datos de sucesos) Inicia un grabador de sucesos con una función de lector de sucesos donde el comprobador de seguimiento tiene una conexión no DASD con el controlador. Es decir, donde el comprobador de seguimiento está conectado por un enlace VTAM, XCF, o TCP/IP o donde el grabador de sucesos se inicia en el mismo espacio de direcciones que el controlador. No se puede especificar EWSEQNO donde se especifica HOSTCON(DASD) en la sentencia TRROPTS. EWSEQNO elimina la necesidad de una tarea de lector de sucesos independiente. El grabador de sucesos graba sucesos de seguimiento de trabajos al conjunto de datos de sucesos, y también envía los sucesos a la comunicación de manejo de tareas con el controlador. Esta función puede mejorar el rendimiento porque Tivoli Workload Scheduler for z/OS no necesita grabar sucesos al conjunto de datos de sucesos y volver a leerlos de nuevo. Si el comprobador de seguimiento no puede comunicarse con el controlador, el grabador de sucesos sigue compilando sucesos y los graba en el conjunto de datos de sucesos. Cuando se restablece la conexión, estos sucesos son enviados al controlador para ser procesados. El número de EWSEQNO no debe ser el mismo que el número de la secuencia de un lector de sucesos en el mismo nodo. El número de secuencia de un conjunto de datos de sucesos en un nodo puede se de 1 a 16. Nota: EWSEQNO no se usa para compilar el ddname del grabador de sucesos en el procedimiento JCL del comprobador de seguimiento, como sucede con la palabra clave ERSEQNO de la sentencia ERDROPTS para un controlador. El ddname es siempre EQQEVDS. EWWAIT(límite de espera|10) Define cuánto tiempo (en segundos) espera el grabador de sucesos antes de volver a comprobar el conjunto de datos de envío/liberación después de que hayan sido leídos todos los registros. El valor de límite de espera sólo se usa cuando se ha especificado SUREL(YES). HOLDJOB(USER|YES|NO) La sentencia HOLDJOB le dice al grabador de sucesos de Tivoli Workload Scheduler for z/OS si debe poner trabajos en estado 'mantener' cuando son introducidos en este sistema para que puedan ser liberados más adelante. Esto puede ser necesario si algunos de los trabajos planificados por Tivoli Workload Scheduler for z/OS no son enviados por Tivoli Workload Scheduler for z/OS sino que son un proceso ajeno a IBM Tivoli Workload Scheduler for z/OS. Para evitar la posibilidad de que dichos trabajos se ejecuten antes de que sus predecesores estén terminados, deben mantenerse cuando entran en el sistema y liberarse en el momento adecuado. Use HOLDJOB(NO) cuando los trabajos planificados por Tivoli Workload Scheduler for z/OS sean siempre enviados automáticamente por Tivoli Workload Scheduler for z/OS. Este es el método de ejecución de trabajos preferido porque es el más sencillo y supone la menor carga. Cuando se especifica HOLDJOB(NO), Tivoli Workload Scheduler for z/OS no mantiene ni libera ningún trabajo. Si tiene trabajos planificados por Tivoli Workload Scheduler for z/OS que, por alguna razón, deben ser enviados por un proceso ajeno a Tivoli Workload Scheduler for z/OS, HOLDJOB(USER) es la opción preferida. Cuando se especifica HOLDJOB(USER), Tivoli Workload Scheduler for z/OS no mantiene ningún trabajo.En lugar de eso, debe asegurarse de que los trabajos Capítulo 1. Definición de sentencias de inicialización 57 EWTROPTS planificados por Tivoli Workload Scheduler for z/OS enviados por métodos ajenos a Tivoli Workload Scheduler for z/OS sean puestos en estado 'mantener'. Esto significa que dichos trabajos deberán tener el parámetro TYPRUN=HOLD en sus tarjetas de trabajo. Estos trabajos son después liberados automáticamente por Tivoli Workload Scheduler for z/OS, tal y como sigue: v Inmediatamente si las opciones de la operación especifican HOLD/RELEASE=NO v Cuando se cumplen los criterios de envío normales si las opciones de la operación especifican HOLD/RELEASE=YES. HOLDJOB(YES) es la opción menos preferida de las tres. Tenga en cuenta HOLDJOB(YES) sólo si tiene trabajos planificados por Tivoli Workload Scheduler for z/OS que: 1. No pueden ser enviados por Tivoli Workload Scheduler for z/OS 2. No tienen TYPRUN=HOLD especificado en sus tarjetas de trabajo. Nota: Cuando se especifica HOLDJOB(YES), la subtarea del grabador de sucesos de Tivoli Workload Scheduler for z/OS pone todos los trabajos que entran en el sistema en estado 'mantener'. Algunos trabajos son planificados por Tivoli Workload Scheduler for z/OS y no pueden ser ejecutados inmediatamente; por ejemplo, si no se han terminado los predecesores. El grabador de sucesos debe mantener todos los trabajos porque no puede determinar si un trabajo en particular es planificado por Tivoli Workload Scheduler for z/OS o no. (No tiene acceso al plan actual de Tivoli Workload Scheduler for z/OS.) Para cada trabajo que entre y sea mantenido en el sistema, el grabador de sucesos crea un registro de sucesos. El gestor de sucesos de Tivoli Workload Scheduler for z/OS, que procesa todos los registros de sucesos, comprueba después el plan actual para determinar qué trabajos mantenidos son planificados por Tivoli Workload Scheduler for z/OS y cuáles no. Los trabajos ajenos a Tivoli Workload Scheduler for z/OS son inmediatamente liberados. Los trabajos planificados por Tivoli Workload Scheduler for z/OS permanecen en espera hasta que sus predecesores están terminados y entonces son liberados automáticamente. El resultado es que: v Los trabajos planificados por Tivoli Workload Scheduler for z/OS se ejecutan en la secuencia correcta según el plan actual. v Los trabajos ajenos a Tivoli Workload Scheduler for z/OS son mantenidos por el grabador de sucesos y posteriormente liberados por el gestor de sucesos cuando se sabe que son trabajos ajenos a Tivoli Workload Scheduler for z/OS. Notas: 1. Tivoli Workload Scheduler for z/OS no usa conexiones VTAM, XCF, o TCP/IP para transmitir mandatos de liberación para trabajos ajenos a Tivoli Workload Scheduler for z/OS. Si especifica HOLDJOB(YES), los mandatos de liberación para trabajos mantenidos que no están en el plan actual son transmitidos mediante NJE a un sistema de comprobador de seguimiento. El comprobador de seguimiento debe ser parte de la misma red de NJE que el controlador. 58 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste EWTROPTS 2. Si especifica HOLDJOB(USER), este valor es válido incluso si la subtarea de grabador de sucesos no está activa. Para HOLDJOB(YES), se usa el valor predeterminado NO cuando la subtarea de grabador de sucesos no está activa. PRINTEVENTS(NO|ALL|END) Define cómo Tivoli Workload Scheduler for z/OS debe crear sucesos de impresión (tipo 4). Especifique NO si no desea realizar seguimiento a las operaciones de impresión. No se crean sucesos de impresión. Especifique ALL si los sucesos de impresión deben reflejar el tiempo real de impresión de las operaciones. El tiempo que una operación está en estado I (interrumpida) no se incluye en el tiempo de impresión total. Tivoli Workload Scheduler for z/OS crea sucesos de impresión cuando se interrumpe una operación y cuando se ha terminado. Especifique END si los sucesos de impresión deben crearse cuando se ha terminado la impresión SYSOUT. END es el valor predeterminado inicial. Use END si desea realizar seguimiento a operaciones de impresión pero no hace falta que el tiempo total refleje el tiempo real de impresión. Es decir, el tiempo total incluirá el tiempo durante el que estuvo interrumpida la impresora. El valor inicial de PRINTEVENTS sigue en vigor hasta que se realice una IPL (carga de programa inicial) o hasta que se especifique la palabra clave con un valor distinto. RETCODE(HIGHEST|LAST) Define cómo el grabador de sucesos crea un código de retorno para un trabajo o una tarea iniciada para el registro de sucesos con final de trabajo (3J). Si especifica HIGHEST, el grabador de sucesos crea un registro de sucesos con el código de retorno más alto de todos los pasos realizados. | | | | | | Si especifica LAST, el grabador de sucesos crea un registro de sucesos con el código de retorno del paso realizado en último lugar. En detalle: v Si todos los pasos fallan, el código de error de la operación se crea a partir del código abend del último paso que falló. v Si todos los pasos fallan, excepto para el último, que se desechó, el código de error de la operación se crea a partir del código abend del primer paso que falló. Nota: El valor de la palabra clave es válido hasta que especifique un valor distinto y reinicie Tivoli Workload Scheduler for z/OS. SDEPFILTER(startpos,stringvalue) Define si y cómo el planificador debe comprobar el nombre del programador de la tarjeta JOB, para decidir si se debe producir un suceso de final de paso. Es útil en concreto si se utiliza la dependencia del nivel de paso, para evitar especificar STEPEVENTS(ALL), que puede afectar al rendimiento del planificador. Consta de dos elementos: startpos Un entero entre 1 y 20, que es la longitud máxima del nombre del programador de la tarjeta JOB. stringvalue Una cadena de caracteres con una longitud máxima de 20 caracteres. Capítulo 1. Definición de sentencias de inicialización 59 EWTROPTS Si el nombre del programador contiene caracteres especiales, por ejemplo un apóstrofe intercalado, al especificar startpos considere la forma final del nombre y excluya los caracteres de control. Por ejemplo, si el nombre del programador contiene ’T.O’’NEILL’, especifique SDEPFILTER(5,NEILL) para filtrar por NEILL. Si se omite esta palabra clave, el planificador no comprueba el nombre del programador de la tarjeta JOB; de lo contrario, el planificador lo comprueba, utilizando startpos como posición inicial desde la que se puede buscar una coincidencia con stringvalue. Si se encuentra una coincidencia, el suceso de fin de paso se produce siempre, con independencia de otros criterios especificados, por ejemplo el valor STEPEVENTS o los parámetros de salida de EQQUX004. SKIPDATE(aammdd|860101) Define un límite superior en la antigüedad de los registros del conjunto de datos de envío/liberación. El grabador de sucesos no usa registros creados antes de la fecha de límite de omisión. La fecha de límite de omisión se especifica con el formato aammdd, donde aa es el año, mm el mes y dd el día. El valor de límite de omisión se usa sólo si se especifica SUREL(YES). SKIPTIME(hhmm|0000) Define un límite superior en la antigüedad de los registros del conjunto de datos de envío/liberación. El grabador de sucesos no usa registros creados antes de la hora de límite de omisión en la fecha de límite de omisión. La hora de límite de omisión se especifica con el formato hhmm, donde hh es la hora en el rango 00 a 23 y mm son los minutos en el rango 00 a 59. El valor de límite de omisión se usa sólo si se especifica SUREL(YES). STEPEVENTS(ALL|NZERO|ABEND) La opción de sucesos por pasos define cómo los pasos de trabajo que están finalizando son procesados por Tivoli Workload Scheduler for z/OS. Si se especifica ABEND, se crea y se graba un suceso de final de paso en el conjunto de datos de sucesos sólo para pasos de trabajos con terminación anómala. Si se especifica ALL, se crea un suceso de final de paso para todos los pasos de trabajo que están finalizando. Especifique este valor sólo si utiliza uno de los siguientes elementos: v Recuperación de trabajos automática, para detectar un paso desechado o para restringir la acción de recuperación a un paso dentro de un procedimiento JCL. v Dependencia del nivel del paso. Este valor puede afectar al rendimiento del planificador, así que plantéese utilizar el parámetro SDEPFILTER como alternativa. Si se especifica NZERO, se crea un suceso de final de paso para todos los pasos de trabajo que terminan con un código de terminación distinto de cero. Nota: El valor de la palabra clave es válido hasta que especifique un valor distinto y reinicie Tivoli Workload Scheduler for z/OS. SUREL(YES|NO) Especifique YES si un controlador envía trabajos a este sistema mediante un conjunto de datos de envío/liberación. YES sólo puede especificarse si también se especifica OPCHOST(NO) en la sentencia OPCOPTS (para obtener detalles, 60 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste EWTROPTS consulte la “OPCOPTS” en la página 120). El conjunto de datos de envío/liberación es definido por el ddname de EQQSUDS. Ejemplos EWTROPTS EWSEQNO(1) 1 STEPEVENTS(NZERO) 2 RETCODE(HIGHEST) 3 SDEPFILTER(5,NEILL)4 En este ejemplo de una sentencia EWTROPTS: 1 El grabador de sucesos se inicia con una tarea de grabador de sucesos. El grabador de sucesos recoge información de sucesos y la graba en el conjunto de datos de sucesos. También envía la información de sucesos al controlador. (El comprobador de seguimiento se conecta al controlador mediante XCF o NCF, o el comprobador de seguimiento y controlador se inician en el mismo espacio de direcciones.) 2 Tivoli Workload Scheduler for z/OS crea un suceso de final de paso (tipo 3S) sólo para pasos de trabajo que terminan con un código de terminación distinto de cero. 3 El grabador de sucesos crea un registro de sucesos de final de paso (3J) con el código de retorno más alto de todos los pasos realizados. 4 El planificador crea un suceso de punto final sólo para los trabajos que especifiquen ’T.O’’NEILL’ en el nombre del programador de la tarjeta JOB. Capítulo 1. Definición de sentencias de inicialización 61 EXITS EXITS Propósito La sentencia EXITS define las opciones de salida a Tivoli Workload Scheduler for z/OS. Es aplicable a las salidas de Tivoli Workload Scheduler for z/OS cuyos nombres tenga el prefijo EQQUX0. Puede usar la sentencia EXITS para que Tivoli Workload Scheduler for z/OS deje de intentar cargar una salida específica. También puede usar EXITS para cambiar el nombre predeterminado del módulo de carga. De modo predeterminado, el comprobador de seguimiento intenta cargar las salidas EQQUX000, EQQUX004, EQQUX005 y EQQUX006. De modo predeterminado, el controlador intenta cargar las sdalidas EQQUX000, EQQUX001, EQQUX002, EQQUX003, EQQUX007, EQQUX009, EQQUX011, EQQUX013, EQQUX014 y EQQUXSAZ. EXITS se define en el miembro de la biblioteca EQQPARM tal y como se especifica con el parámetro PARM de la sentencia JCL EXEC. Formato EXITS CALLnn( YES NO X ) LOADnn( EQQUX0nn nombre de módulo ) Parámetros CALLnn(NO|X|YES) Especifica si debe cargarse una salida. La salida es la salida de Tivoli Workload Scheduler for z/OS con sufijo nn, o su alternativa tal y como se especifica con la palabra clave LOADnn. El valor 'X' permite que EQQUX007 vea el estado ampliado 'X' (en espera de recursos especiales). Si especifica este valor con la sentencia CALL07, se llama a la salida EQQUX007 y siempre que una operación cambia su estado Tivoli Workload Scheduler for z/OS explora la cadena de recursos especiales para ver si alguna operación necesita alguno de duchos recursos. Use esta característica sólo cuando sea necesario para no reducir el rendimiento. LOADnn(nombre de módulo|EQQUX0nn) Especifica un módulo de carga alternativo que es llamado en lugar de la salida predeterminada llamada EQQUX0nn. Ejemplos EXITS CALL04(NO) LOAD00(TWS00) 1 2 En este ejemplo de sentencia EXITS, aplicable a un comprobador de seguimiento: 62 1 No se carga la salida EQQUX004. 2 Se carga un módulo llamada TWS00 en lugar de la salida EQQUX000. IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste EXITS El subsistema intenta carga las salidas EQQUX005 y EQQUX006 de modo predeterminado. Para obtener más información sobre las salidas de Tivoli Workload Scheduler for z/OS, consulte Capítulo 4, “Salidas de Tivoli Workload Scheduler for z/OS”, en la página 225. Capítulo 1. Definición de sentencias de inicialización 63 FLOPTS FLOPTS Propósito La sentencia FLOPTS define las opciones de la tarea de obtención de registro de trabajo (FL). Un controlador usa esta sentencia cuando se especifica OPCOPTS RCLEANUP (YES). Nota: Si ha cambiado el nombre de destino en los parámetros SNADEST, XCFDEST o TCPDEST en la fase de migración, especifique los nombres de destino antiguo y nuevo, según el rastreador y las consideraciones del almacén de datos en la sección Migración de la Guía de instalación. Formato FLOPTS CTLLUNAM( Nombre de unidad lógica ) CTLMEM( NombreMemXCF ) DSTGROUP( NombreGrupoXCF ) SNADEST( , TrackerDest.DSTdest TCPDEST( , TrackerDest.DSTdest XCFDEST( , TrackerDest.DSTdest ) ) ) Parámetros CTLLUNAM(Nombre de unidad lógica) Define el nombre de unidad lógica de la aplicación VTAM que identifica el controlador en la conexión SNA entre el controlador y el almacén de datos. Es obligatoria si se usa la conexión SNA entre el controlador y el almacén de datos, y debe ser la misma especificada en la sentencia DSTOPTS CTLLUNAM del almacén de datos. Debe al menos especificar DSTGROUP junto con CTLLMEM o CTLLUNAM. CTLMEM(NombreMemXCF) Define el nombre de miembro XCF que identifica el controlador en la conexión XCF entre el controlador y el almacén de datos. Debe especificarse junto con la palabra clave DSTGROUP. Es obligatoria si se usa la conexión XCF entre el controlador y el almacén de datos, y debe ser la misma especificada en la sentencia DSTOPTS CTLMEM del almacén de datos. DSTGROUP(NombreGrupoXCF) Define el nombre de grupo XCF que identifica el controlador en la conexión XCF entre el controlador y el almacén de datos. Debe especificarse junto con la palabra clave CTLMEM. Es obligatoria si se usa la conexión XCF entre el controlador y el almacén de datos. 64 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste FLOPTS El grupo XCF definido para conectar el controlador al almacén de datos debe se distinto del definido en el grupo XCFOPTS para conectar el controlador al comprobador de seguimiento de z/OS. SNADEST(TrackerDest.DSTdest) Define una tabla de pares de destinos del comprobador de seguimiento y destinos de almacén de datos, separados por un punto, cuando los destinos del almacén de datos son nombres de unidades lógicas. SNADEST es usada por la FL (tarea de obtención de registro de trabajo) para decidir de qué almacén de datos se recuperará el registro de trabajo. Pueden asociarse varios destinos de comprobador de seguimiento al mismo almacén de datos sólo en un sistema donde se comparte el archivo spool (por ejemplo, JES2 MAS). El destino de comprobador de seguimiento de 8 asteriscos (********) identifica el almacén de datos asociado a un comprobador de seguimiento ejecutado en el mismo espacio de direcciones que el controlador. Puede conectar el controlador a almacenes de datos de SNA y XCF al mismo tiempo, es decir, puede especificar SNADEST y XCFDEST juntos, pero no puede especificar el mismo comprobador de seguimiento o los mismos destinos de almacenes de datos en SNADEST y XCFDEST. Debe especificar al menos SNADEST o XCFDEST. Al utilizar una conexión DASD compartida debe especificar el DDname del conjunto de datos de envío/liberación. Al utilizar una conexión SNA, debe indicar el nombre LU del rastreador. TCPDEST(TrackerDest.DSTdest) Define una tabla de pares de destinos de comprobador de seguimiento y destinos del almacén de datos, separados por un punto, cuando los destinos son destinos TCP/IP. Las siguientes reglas son aplicables a los subvalores de destino: v El nombre TrackerDest puede tener hasta 8 caracteres alfanuméricos. Junto con el nombre de host o la dirección IP, se usa para identificar tlos socios de comunicación. Este subvalor es necesario. v El DSTdest se compone de un nombre de host o dirección IP y opcionalmente un número de puerto: – El nombre de host o la dirección IP pueden tener hasta 52 caracteres alfanuméricos. Puede contener un nombre de host o dirección IP en formato IPV4 o IPV6. Este valor debe escribirse entre comillas. Este subvalor es necesario. – El número de puerto puede tener hasta 5 caracteres numéricos. Los valores válidos están comprendidos entre 0 y 65535. Este subvalor es opcional. El valor predeterminado es 0, lo cual significa que se acepta cualquier número de puerto. v El nombre TrackerDest y el nombre DSTdest deben estar separados por un punto. v Los valores requeridos y el número de puerto deben estar separados por una barra oblicua. TCPDEST es usada por la tarea de obtención de registro de trabajo (FL) para decidir de qué almacén de datos se recuperará el registro de trabajo. Pueden asociarse varios destinos de comprobador de seguimiento al mismo almacén de datos sólo en un sistema donde se comparte el archivo spool (por ejemplo, JES2 MAS). En este caso, debe usar el mismo formato de dirección para los distintos destinos. El destino del comprobador de seguimiento marcado con 8 asteriscos (********) identifica el almacén de datos asociado a un comprobador de seguimiento ejecutado en el mismo espacio de direcciones que el controlador. Puede conectar el controlador a almacenes de datos de SNA, XCF Capítulo 1. Definición de sentencias de inicialización 65 FLOPTS y TCPIP al mismo tiempo, es decir, puede especificar SNADEST, XCFDEST y TCPDEST juntos, pero no puede especificar el mismo comprobador de seguimiento o los mismos destinos de almacenes de datos en SNADEST, TCPDEST o XCFDEST. Debe especificar al menos uno de los siguientes destinos: SNADEST, XCFDEST o TCPDEST. XCFDEST(TrackerDest.DSTdest) Define una tabla de pares de destinos del comprobador de seguimiento y destinos de almacén de datos, separados por un punto, cuando los destinos del almacén de datos son nombres de miembros XCF. XCFDEST es usada por la FL (tarea de obtención de registro de trabajo) para decidir de qué almacén de datos se recuperará el registro de trabajo. Pueden asociarse varios destinos de comprobador de seguimiento al mismo almacén de datos sólo en un sistema donde se comparte el archivo spool (por ejemplo, JES2 MAS). Debido a que la función de reinicio y limpieza añade una tarjeta de trabajo a los procedimientos para operaciones de estaciones de trabajo STC planificadas al mismo tiempo que añade las sentencias JCL de salida //TIVDSTxx, existen algunas excepciones a las instrucciones anteriores si desea usar la función de reinicio y limpieza. El JCL para una tarea iniciada puede contener una tarjeta de trabajo sólo si el JCL está en un conjunto de datos en las concatenaciones IEFPDSI o IEFJOBS de MSTJCLxx cuando se emite el mandato. El valor XCFDEST (********.DSTdest) identifica el almacén de datos asociado a un comprobador de seguimiento ejecutado en el mismo espacio de direcciones o en la misma partición lógica (LPAR) que el controlador. Puede conectar el controlador a almacenes de datos de SNA y XCF al mismo tiempo, es decir, puede especificar XCFDEST y SNADEST juntos, pero no puede especificar el mismo comprobador de seguimiento o los mismos destinos de almacenes de datos en XCFDEST y SNADEST. Debe especificar al menos XCFDEST o SNADEST. Ejemplos FLOPTS SNADEST (SNATRK1.SNAD001) XCFDEST (XCFTRK1.XCFD001) CTLLUNAM (LU0001) DSTGROUP (XCFGRP1) CTLMEM (GRP1001) TCPDEST(TRK1.’9.12.134.9’/5555) 1 2 3 4 5 6 En este ejemplo de una sentencia FLOPTS: 66 1 SNATRK1 es el destino de comprobador de seguimiento y SNAD001 es el destino de almacén de datos separados por un punto cuando el destino es un nombre de unidad lógica. 2 XCFTRK1 es el destino de comprobador de seguimiento y XCFD001 es el destino de almacén de datos separados por un punto cuando el destino es un nombre de miembro XCF. 3 LU0001 es el nombre de unidad lógica del servidor que se comunica con el sistema del controlador. 4 XCFGRP1 es el nombre del grupo XCF al que el sistema de Tivoli Workload Scheduler for z/OS debe unirse. 5 GRP1001 es un miembro del grupo XCF XCFGRP1. IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste FLOPTS 6 TRK1 identifica un enlace TCP/IP con un almacén de datos y sus detalles se definen en la palabra clave TCPDEST. Capítulo 1. Definición de sentencias de inicialización 67 HTTPOPTS | | HTTPOPTS Propósito | La sentencia HTTPOPTS define las opciones para rastrear trabajos y recuperar registros de ejecución de trabajos que se emiten en Tivoli Workload Scheduler for z/OS agents. | | | Formato | | | HTTPOPTS CLNTHREADNUM( | | 10 número de hebras ) 15 Intervalo de tiempo de espera de HTTP CONNTIMEOUT( | | ) 1 número de hebras JLOGTHREADNUM( | | ) 100 número de líneas JOBLOGMAXLINES( | | ) JOBLOGRETRIEVAL( | | ONDEMAND ONERROR ) JOBLOGSECTION( FIRSTLAST FIRST LAST ) HOSTNAME( | | | | nombre de host local nombrehost dirección IP HTTPPORTNUMBER( Puerto HTTP ) 10 número de hebras SRVTHREADNUM( | | ) ) SSLAUTHMODE( CAONLY STRING ) SSLAUTHSTRING( | | | | | | ) SSLKEYRING( nombre de archivo de db de anillo de clave SSL nombre de archivo de psw de anillo de clave SSL ) SSLKEYRINGTYPE( SAF USS ) SSLPORT( 512 número de puerto SSL ) TCPIPJOBNAME( TCPIP Tarea iniciada TCPIP | 68 ) SSLKEYRINGPSW( | | tws serie de SSL IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste ) HTTPOPTS | | TCPIPTIMEOUT( | | ) USRMEM( | | 300 Intervalo de tiempo de espera de TCPIP USRINFO nombre de miembro ) VARTABLES( GLOBAL APPL tabla1,tabla2,... ) VARFAIL( YES NO ) VARSUB( YES NO ) | | Parámetros | | | CLNTHREADNUM(número de hebras|10) El número de hebras que utiliza la tarea de cliente HTTP para enviar más de una solicitud a la vez. Los valores válidos están comprendidos entre 5 y 100. | | | | CONNTIMEOUT(intervalo de tiempo de espera de HTTP|15) El tiempo (en segundos) que una conexión HTTP espera antes de que se supere un tiempo de espera. Los valores válidos están comprendidos entre 1 y 10000. | | | | JLOGTHREADNUM(número de hebras|1) El número de hebras que utiliza la tarea de cliente HTTP para gestionar las solicitudes sobre el registro de trabajos. Este parámetro es válido sólo para Tivoli Workload Scheduler para agentes z/OS. | | | Los valores válidos están comprendidos entre 0 y 100. 0 significa que las solicitudes del registro de trabajos se gestionan como el resto de solicitudes enviadas por la tarea del cliente HTTP. | | | | JOBLOGMAXLINES(número de líneas|100) El número máximo de líneas que un recuperador de registros de trabajos puede devolver para un solo registro de trabajos. Este parámetro es válido sólo para Tivoli Workload Scheduler para agentes z/OS. | | | | | | | Los valores válidos están comprendidos entre 0 y 99999. Para especificar qué sección del registro de trabajos se debe recuperar, configure la palabra clave JOBLOGSECTION. JOBLOGRETRIEVAL(ONERROR|ONDEMAND) Este parámetro define la política de recuperación de registros de trabajos para las operaciones que se ejecutan en las estaciones de trabajo z-centric y dinámicas. Los valores válidos son estos: | | | ONDEMAND El valor predeterminado. El usuario debe realizar una solicitud explícitamente para recuperar el registro de trabajos. | | | | ONERROR Después de que un trabajo se ejecuta y acaba en error, el registro de trabajos se recupera y envía automáticamente. Los cambios manuales en el error no desencadenan el proceso de recuperación para empezar. | | | | JOBLOGSECTION(FIRST|LAST|FIRSTLAST) La sección del registro de trabajos recuperados desde un agente Tivoli Workload Scheduler for z/OS que se deben mostrar. Los valores válidos son estos: Capítulo 1. Definición de sentencias de inicialización 69 HTTPOPTS | | | | | FIRSTLAST Se recuperan las secciones inicial y última del registro de trabajos. Si el número total de líneas que visualizar supera el valor de JOBLOGMAXLINES, la parte central se descarta y se sustituye con una línea de guiones bajos. | | | FIRST Sólo se recupera la sección inicial del registro de trabajos. Si el número total de líneas que visualizar supera el valor de JOBLOGMAXLINES, la parte última se descarta y se sustituye con una línea de guiones bajos. | | | LAST Sólo se recupera la sección última del registro de trabajos. Si el número total de líneas que visualizar supera el valor de JOBLOGMAXLINES, la primera parte se descarta y se sustituye con una línea de guiones bajos. | | | | | | | | HOSTNAME(nombre de host|dirección IP| nombre de host local) El nombre de host o la dirección IP usados por el componente del servidor HTTP. Puede tener hasta 52 caracteres alfanuméricos. Especifica un nombre de host o dirección IP en formato IPV4 o IPV6. Este valor debe escribirse entre comillas. Si no especifica este parámetro aquí, el sistema busca el nombre indicado para el mismo parámetro en la sentencia CPOPTS. Si no encuentra ningún nombre aquí, utiliza el valor predeterminado, que es la dirección IP devuelta por TCP/IP. | | | HTTPPORTNUMBER(puerto HTTP|511) El número de puerto utilizado por el servidor HTTP para escuchar conexiones no de SSL. Los valores válidos están comprendidos entre 0 y 65535. | | | | SRVTHREADNUM(número de hebras|10) El número de hebras que utiliza la tarea de servidor HTTP para procesar más de una solicitud a la vez. Los valores válidos están comprendidos entre 2 y 100. | | SSLAUTHMODE(STRING|CAONLY) El tipo de autenticación SSL. Los valores válidos son: | | | | CAONLY El planificador comprueba la validez del certificado verificando que una entidad emisora de certificados haya emitido el certificado de interlocutor. No se comprueba la información contenida en el certificado. Éste es el valor predeterminado. | | | | STRING El planificador comprueba la validez del certificado tal y como se describe en la opción CAONLY. También verifica que el nombre común (CN) del Asunto del certificado coincide con la serie especificada en el parámetro SSLAUTHSTRING. | | | SSLAUTHSTRING(serie SSL|tws) La serie SSL usada para verificar la validez del certificado cuando se establece SSLAUTHMODE como STRING. La serie puede contener hasta 64 caracteres. | | | SSLKEYRING(Nombre de archivo de base de datos de anillo de claves de SSL) Si SSLKEYRINGTYPE es SAF, este parámetro especifica el anillo de la clave SAF para conectarse con los certificados de seguridad. | | | Si SSLKEYRINGTYPE es USS, este parámetro identifica la base de datos que contiene las claves y los certificados. Está formada por un nombre de directorio y nombre de archivo con SSL, con formato SSLworkdir/TWS.kbd. | Este parámetro distingue entre mayúsculas y minúsculas. | | SSLKEYRINGTYPE(USS|SAF) Especifica si el archivo de anillo de claves es un archivo USS de la base de 70 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste HTTPOPTS | | datos de claves o un anillo de claves SAF. Si este valor se establece en SAF, puede utilizar el mandato RACF para gestionar las conexiones SSL. | | | | | SSLKEYRINGPSW(nombre de archivo psw del archivo de claves SSL) Si SSLKEYRINGTYPE es USS, especifica el archivo que contiene la contraseña de la clave. Está formada por un nombre de directorio y nombre de archivo con SSL, con formato SSLworkdir/TWS.sth. Este parámetro distingue entre mayúsculas y minúsculas. | | | SSLPORT(número de puerto SSL|512) El número de puerto SSL utilizado por el servidor HTTP para escuchar las conexiones SSL. Los valores válidos están comprendidos entre 0 y 65535. | | | Si desea inhabilitar la conexión SSL, puede hacer una de estas dos acciones: v No especifique ni claves SSLKEYRING ni SSLPORT. v Especifique SSLPORT(0). | | | | | | TCPIPJOBNAME(tarea iniciada TCPIP|TCPIP) El nombre de la tarea iniciada TCP/IP que se está ejecutando en el sistema z/OS donde se ha instalado el planificador. Si no especifica este parámetro aquí, el sistema busca el nombre indicado para el mismo parámetro en la sentencia CPOPTS. Si no encuentra ningún nombre aquí, utiliza la tarea iniciada predeterminada llamada TCPIP. | | | TCPIPTIMEOUT(intervalo de tiempo de espera de TCPIP|300) El tiempo (en segundos) que una solicitud HTTP espera antes de que se supere el tiempo de espera. Los valores válidos están comprendidos entre 1 y 10000. | | | | | | USRMEM(nombre de miembro|USRINFO) El miembro PARMLIB en el que se almacenan las definiciones de usuario. Si trabaja con soluciones tolerantes a errores y globales de z-centric a la vez, asegúrese de que el miembro que establezca aquí sea distinto del miembro establecido en la palabra clave USRMEM o el entorno global de tolerancia a errores. | | Esta palabra clave es necesaria sólo si se ejecutan trabajos en estaciones de trabajo Windows en las que se solicite la contraseña del usuario. | | | | | | | | VARTABLES(GLOBAL|APPL|tabla1,tabla2,...) Se aplica a tipos de trabajo con opciones avanzadas definidas desde Dynamic Workload Console e identifica una lista de tablas de variables que deben buscarse, y el orden de búsqueda. APPL indica la tabla de variables de la aplicación. GLOBAL indica la tabla definida en la palabra clave GTABLE del controlador OPCOPTS. El número máximo de caracteres que se puede especificar para el nombre de tabla es 16, y no se puede especificar más de 16 tablas en la lista. | | | | | | | VARFAIL(NO|YES) Se aplica a tipos de trabajo con opciones avanzadas definidas desde Dynamic Workload Console. Establezca esta palabra clave en YES de manera que si se produce un error de sustitución de variables, el trabajo dé como resultado un error JCL (OJCV). Especifique NO de manera que la cadena de variables siga sin cambiar, sin sustituirla con un valor y que no informe de un error JCL (OJCV). | | | | VARSUB(NO|YES) Se aplica a tipos de trabajo con opciones avanzadas definidas desde Dynamic Workload Console e indica si se debe habilitar la sustitución de variables. Especifique YES de para que se realice la exploración de variables para tipos Capítulo 1. Definición de sentencias de inicialización 71 HTTPOPTS de trabajos con opciones avanzadas. Especifique NO para que la serie de variables permanezca sin cambios y no se sustituya con un valor. | | 72 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste INCLUDE INCLUDE Propósito La sentencia INCLUDE reduce el tamaño del miembro de biblioteca de parámetros que contiene las sentenciase OPCOPTS y JTOPTS. Además, esta sentencia reduce las actividades de mantenimiento para este miembro. Cuando se usa la sentencia INCLUDE, la definición de la tabla NOERROR puede ser proporcionada por varios miembros de la biblioteca EQQPARM. Cada uno de estos miembros puede residir en conjuntos de datos diferentes. Los conjuntos de datos pueden protegerse con un perfil RACF distinto. El efecto neto es que hace posible dividir la información de NOERROR en varias partes, necesitando cada una de ellas una autoridad de acceso diferente. Nota: Si especifica varios miembros, no puede usar el mandato NOERRMEM para actualizar la lista de NOERROR. Los cambios a la lista de NOERROR se hacen efectivos cuando se reinicia el controlador. Formato , INCLUDE NOERROR( DEPT1, DEPT2 ) Parámetros NOERROR(lista de miembros) Esta palabra clave se usa para solicitar que Tivoli Workload Scheduler for z/OS lea información de NOERROR de otros miembros de la biblioteca EQQPARM. Los miembros de la biblioteca de parámetros especificados con esta palabra clave sólo pueden contener sentencias NOERROR. Ejemplos INCLUDE NOERROR(DEPT1, DEPT2) En este ejemplo, la información de NOERROR se recupera desde dos miembros, DEPT1 y DEPT2, de la biblioteca EQQPARM. Capítulo 1. Definición de sentencias de inicialización 73 INIT INIT Propósito La sentencia INIT define las opciones de tiempo de ejecución para procesar solicitudes enviadas a Tivoli Workload Scheduler for z/OS desde una aplicación PIF. . Los parámetros especificados en la sentencia INIT alteran temporalmente los valores especificados en la solicitud de INIT de la aplicación PIF. INIT se define en el archivo de parámetros identificado por la sentencia EQQYPARM DD en el JCL de la aplicación PIF y en el archivo de parámetros identificado por la sentencia EQQPARM DD en el procedimiento del servidor. Nota: Si planifica ejecutar aplicaciones PIF muchas veces por día desde un espacio de direcciones no de TSO y de larga ejecución (por ejemplo, NetView), para evitar una falta de almacenamiento no indique el ddname EQQYPARM. En lugar de ello, indique los parámetros en la aplicación PIF o en la sentencia de inicialización INTFOPTS del controlador. Cuando ejecute una aplicación PIF indicando el ddname EQQYPARM, se debe establecer un entorno TSO cada vez, y algunos de los recursos permanecen asignados hasta que la tarea finaliza. Esto puede conducir a una falta de almacenamiento si los mandatos se emiten muchas veces. Formato INIT ADOICHK( NO valor ADOPSEG( VERS0 ) ) CALENDAR( nombre de calendario ) CWBASE( año base para la ventana de siglo de PIF DATINT( N Y LUNAME( Nombre de unidad lógica ) ) 711231 991231 cccccc HIGHDATE( ) ) ERROR IGNORE OIWSNAME( ) REMHOSTNAME( nombrehost dirección IP ) 425 Puerto TCPIP REMPORTNUMBER( SUBSYS( nombre de subsistema ) TRACE( 0 4 8 ) VERADGRD( 74 ) NO FULL YES ) VERSRWSN( IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste NO FULL YES ) INIT Parámetros ADOICHK(value|NO) Use esta opción para especificar si desea realizar comprobaciones de consistencia AD/OI siempre que se elimine o se modifique una aplicación. Las comprobaciones de consistencia conllevan buscar en la base de datos de descripciones de aplicación en busca de coincidencias para todas las instrucciones de operador de la aplicación. Se elimina cualquier instrucción sin coincidencia. Las comprobaciones se realizan inmediatamente después de completar la acción PIF de descripción de aplicación con un código de retorno cero. Sí Las comprobaciones de consistencia se realizan siempre que se elimina o se sustituye un registro de descripción de aplicación usando la PIF. No (predeterminado) No se realizan comprobaciones de consistencia. ADOPSEG (VERS0) Las aplicaciones/programas PIF pueden usar esta opción para preservar los valores en determinados campos en la parte de operación de las descripciones de aplicación con Sustitución. Si se lee (Seleccionar) la descripción de aplicación y después de actualiza en el almacenamiento intermedio en el que se recibió antes de la actualización (Sustituir), no debe usarse la opción ADOPSEG. Tampoco debe usarse si la descripción de aplicación se copia a un área para actualización y se copian las longitudes totales de los segmentos, incluyendo el campo en blanco al final de cada segmento. La ADOPSEG puede usarse para programas que no definen los campos que siguen a los campos ADOPWSINFO en el segmento ADOP y que no preservan el valor en el campo al final del segmento. Al actualizar una descripción de aplicación, Sustituir, no se actualizan los campos que siguen a ADOPWSINFO en el segmento ADOP y se preservan sus valores actuales. Al crear una descripción de aplicación o añadir una operación a una descripción de aplicación, los campos que siguen a los campos ADOPWSINFO en el segmento ADOP reciben los valores predeterminados. CALENDAR(nombre de calendario) Especifica el calendario predeterminado de Tivoli Workload Scheduler for z/OS. Puede especificar un nombre, de 1 a 16 caracteres, que haga referencia a un calendario de la base de datos de calendarios. Este parámetro es usado por las interfaces de programación sólo si no se especifica ningún calendario en la descripción de aplicación. Es utilizado por interfaces de programación para validar que las opciones EVERY especificadas para un ciclo de ejecución de una aplicación son consistentes con el tiempo final del día laborable del calendario de la aplicación. Si se especifica DEFAULT y no existe ningún calendario con el nombre DEFAULT, todos los días son considerados días laborables y el tiempo final del día laborable se establece como 00.00. Si no se establece este parámetro o no existe el calendario especificado en la base de datos de calendario existente, no se realiza la validación en las opciones EVERY. Las inconsistencias en la definición son resaltadas con un mensaje de aviso durante la creación o modificación de planes a largo plazo. Capítulo 1. Definición de sentencias de inicialización 75 INIT CWBASE(año base para la ventana de siglo de PIF) Especifica el origen para la ventana de siglo usada por la aplicación PIF. Los valores permitidos son del 00 al 99.Si especifica 00, Tivoli Workload Scheduler for z/OS usa la misma representación de fecha en comunicación con la aplicación PIF como en el diálogo. SI especifica 72, se usará la representación de fecha interna de Tivoli Workload Scheduler for z/OS. Este parámetro afecta a la representación de fecha en todas las fechas excepto las fechas de límite de validez y sin efecto predeterminadas. Las fechas predeterminadas son determinadas por el valor del parámetro HIGHDATE o el parámetro PIFHD de la sentencia INTFOPTS. Para obtener más información sobre el año base, consulte el parámetro PIFCWB de la sentencia INTFOPTS. El parámetro CWBASE anula temporalmente el valor global del parámetro PIFCWB de la sentencia INTFOPTS. DATINT(Y|N) La palabra clave permite que distintos usuario serialicen actualizaciones del mismo registro tan pronto como el código PIF maneja la solicitud. El valor predeterminado, N, serializa la actualización del mismo registro sólo inmediatamente antes del acceso VSAM y esto puede provocar resultados imprevisibles para un usuario PIF. Especifique Y si desea obtener la serialización a nivel de PIF. Esto significa que si se inicia un programa PIF que contiene una solicitud de actualización y al mismo tiempo otro programa PIF se está ejecutando con la misma solicitud de actualización, la primera será rechazada y su actualización no será realizada. HIGHDATE(991231|711231|cccccc) Especifica la fecha más reciente presentada a la aplicación PIF en los campos de límite de validez de aplicaciones y ciclos de ejecución. Para obtener más información sobre la fecha más reciente, consulte el parámetro PIFHD de la sentencia INTFOPTS. Puede seleccionar uno de estos valores: 991231 Use este valor si ha especificado el parámetro CWBASE como 72. 711231 Tal y como aparece en el diálogo de Tivoli Workload Scheduler for z/OS. Esta fecha representa el 31 de diciembre de 2071. cccccc Una serie de 6 caracteres para simbolizar la fecha de límite de validez predeterminada, por ejemplo DEFHID. La serie no puede incluir caracteres numéricos. Aparecerá la serie de caracteres y siempre será procesada por Tivoli Workload Scheduler for z/OS como fecha de límite de validez. El parámetro HIGHDATE anula temporalmente el valor global del parámetro PIFHD de la sentencia INTFOPTS. LUNAME(Nombre de unidad lógica) identifica el nombre de nodo de la unidad lógica del servidor que se comunica con el sistema de controlador. Esta palabra clave anula temporalmente el valor del nombre de unidad lógica dado en la solicitud EQQYCOM INIT. Esto sólo es válido si el servidor usa el protocolo APPC. OIWSNAME(IGNORE|ERROR) Especifica si debe ignorarse el argumento de nombre de la estación de trabajo cuando se usa en un programa PIF como argumento de un código de recursos OI/OICOM. 76 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste INIT De modo predeterminado, aparece un mensaje de error, por ejemplo, cuando se solicita una lista OICOM o una eliminación OI con el uso del argumento de nombre de estación de trabajo. El mensaje muestra el uso erróneo del argumento que ya no es importante y no se realiza la lista ni la eliminación. El argumento de nombre de estación de trabajo, cuando existe, simplemente se ignora si se establece la palabra clave OIWSNAME a IGNORE. REMHOSTNAME (nombrehost|dirección IP) El nombre de host o la dirección IP del servidor usados por el programa PIF para comunicarse con el servidor mediante una red TCP/IP. Este parámetro anula temporalmente el valor de REMHOST especificado en la solicitud EQQYCOM INIT. Si especifica el parámetro REMHOSTNAME en la sentencia INIT del procedimiento del servidor, será ignorado. REMHOSTNAME y LUNAME se excluyen mutuamente. REMPORTNUMBER (valor|425) El número de puerto TCP/IP del servidor usado por el programa PIF para comunicarse con el servidor mediante una red TCP/IP. Este parámetro anula temporalmente el valor de REMPORT especificado en la solicitud EQQYCOM INIT. Si especifica el parámetro REMPORTNUMBER en la sentencia INIT del procedimiento del servidor, será ignorado. Los valores válidos están comprendidos entre 0 y 65535. El valor predeterminado es 425. REMPORTNUMBER y LUNAME se excluyen mutuamente. SUBSYS(nombre subsistema) Identifica el nombre del subsistema del controlador para el que se dirige la solicitud. Esta palabra clave anula temporalmente el valor del parámetro RESOURCE en la solicitud EQQYCOM INIT. TRACE(4 |8|0) Define el nivel de información de rastreo que Tivoli Workload Scheduler for z/OS graba en el archivo de diagnóstico (EQQDUMP). Especifique 0, que es el valor predeterminado, si no desea rastrear la información. Especifique 4 si desea información de rastreo parcial. Especifique 8 si desea información de rastreo total. VERADGRD(FULL|YES|NO) Las descripciones de aplicaciones que son miembros de un grupo de aplicaciones tienen el nombre de la definición de grupo en el campo ADGROUPID del segmento ADCOM. VERADGRD controla la verificación de este campo cuando se crea una descripción de aplicación nueva o se sustituye una existente. La verificación se realiza para descripciones de aplicación activas. Especifique FULL para comprobar que la definición de grupo es activa y válida para al menos una parte del período de validez de la descripción de aplicación que se está creando o actualizando. Especificar YES es lo mismo que especificar FULL, excepto que el identificador de grupo de aplicación se acepta si la descripción de aplicación ya tiene este identificador de grupo de aplicación. Podría ser una actualización sin ningún cambio al identificador de grupo de aplicación o la adición de una nueva versión cuando ya hay activas versiones con el mismo identificador de grupo de aplicación. Especificar NO significa que no se realiza ninguna comprobación para verificar que existe el grupo de aplicación. VERSRWSN(FULL|YES|NO) La descripción de recursos especiales, SR, tiene campos que representan Capítulo 1. Definición de sentencias de inicialización 77 INIT estaciones de trabajo, los nombres completos de las estaciones de trabajo o nombres genéricos; el campo SRDWSNAME del segmento SRDWS para estaciones de trabajo conectadas, el campo SRIWSNAME del segmento SRIWS para estaciones de trabajo conectadas a un intervalo. VERSRWSN controla la verificación de estos campos cuando se crea un recurso especial nuevo o se sustituye uno existente. Especifique FULL para verificar los campos de trabajo de la estación de trabajo con el archivo de descripción de estación de trabajo. Los campos de estación de trabajo de la descripción de recursos deben coincidir con al menos una de las descripciones de estación de trabajo. Especificar YES es lo mismo que especificar FULL, excepto que el valor de estación de trabajo se acepta si la descripción de recursos ya tiene el nombre de esta estación de trabajo. Puede ser una actualización sin cambios a los nombres de la estación de trabajo. Especificar NO significa que no se realiza ninguna comprobación para verificar que existe la descripción de estación de trabajo. Ejemplos INIT SUBSYS(OPCB) HIGHDATE(991231) CWBASE(72) LUNAME(SEIBM200.IS4MSV3B) 1 2 3 4 En este ejemplo de una sentencia INIT: 78 1 Una aplicación PIF envía una solicitud al subsistema OPCB. La sentencia anulará temporalmente los valore globales de la sentencia INTFOPTS. 2 La fecha de límite de validez predeterminada será presentada a la aplicación PIF como 991231. 3 72 es el año base para la aplicación PIF. 4 La solicitud se envía al servidor SEIBM200.IS4MSV3B del nodo de la unidad lógica. IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste INTFOPTS INTFOPTS Propósito La sentencia INTFOPTS define las opciones de tiempo de ejecución globales para manejar solicitudes desde interfaces de programación, por ejemplo solicitudes de aplicaciones PIF. Especifique esta sentencia para un controlador o un controlador en reposo. Est sentencia es obligatoria. INTFOPTS se define en el miembro de la biblioteca EQQPARM tal y como se especifica con el parámetro PARM de la sentencia JCL EXEC. Formato INTFOPTS PIFCWB( PIFHD( 711231 991231 cccccc 00 año base para la ventana de siglo de PIF ) ) Parámetros PIFCWB(año base para la ventana de siglo de PIF|00) Define el origen para la ventana de siglo de la PIF. Los valores permitidos son del 00 al 99. El origen es el año que desea representar como 00 en el rango de años que va de 00 a 99 (ventana de siglo). Por ejemplo, si la PIFCWB es 72, entonces 1972 se trata como 00, 1992 como 20 y 2002 como 30. Internamente, Tivoli Workload Scheduler for z/OS trabaja con un formato de dos dígitos para años, por lo tanto las fechas se presentan de 00 a 99. Para manejar correctamente las fechas anteriores y posteriores al 2000, Tivoli Workload Scheduler for z/OS utiliza el año de origen como su año base. Esto significa que, internamente, 1972 se representa como 00, 1995 como 23 y 2071 como 99. Cuando se usan aplicaciones PIF, las fechas internas se presentan a las aplicaciones PIF. La PIFCWB define si las fechas se presentan cuando se almacenan o si se traducen en alguna otra base. Si elige 72 como la PIFCWB, las fechas se presentan al almacenarlas, 1995 se presenta como 22 y 2071 como 99. Elegir 72 hace posible ordenar correctamente las fechas anteriores y posteriores al 2000. Si elige 00 como la PIFCWB, las fechas se presentan tal y como aparecen en los diálogos ISPF; 1995 como 95 y 2071 como 71. Éste es el valor predeterminado. Nota: El ajuste PIFCWB global es anulado temporalmente si un programa PIF especifica el parámetro CWBASE de la sentencia INIT. PIFHD(991231|711231|cccccc) Especifica el valor de fecha más reciente presentado en los campos de límite de Capítulo 1. Definición de sentencias de inicialización 79 INTFOPTS validez predeterminados de las aplicaciones y los ciclos de ejecución. Esta fecha sólo afecta a las fechas con límite de validez predeterminadas. Puede seleccionar uno de estos valores: 991231 Use este valor junto con PIFCWB(72). 711231 Tal y como aparece en el diálogo de Tivoli Workload Scheduler for z/OS. Esta fecha representa el 31 de diciembre de 2071. cccccc Una serie de 6 caracteres para simbolizar la fecha de límite de validez predeterminada, por ejemplo HGHDAT. La serie no puede incluir caracteres numéricos. Definir PIFHD usando una serie de caracteres significa que Tivoli Workload Scheduler for z/OS siempre interpretará esto como la fecha de límite de validez predeterminada. Esta palabra clave es obligatoria. Nota: Si un programa PIF especifica el parámetro HIGHDATE de la sentencia INIT, el valor PIFHD global es anulado temporalmente. Ejemplos INTFOPTS PIFCWB(72) PIFHD(991231) 1 2 En este ejemplo de una sentencia INTFOPTS: 80 1 Las aplicaciones PIF usan 72 como año base. Esto significa que el 1 de enero de 1974 se usa como 020101, y el 1 de enero de 2002 se usa como 300101. 2 Tivoli Workload Scheduler for z/OS presenta 991231 como la fecha de límite de validez predeterminada a las aplicaciones PIF. IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste JCCOPTS JCCOPTS Propósito La sentencia JCCOPTS define las opciones de tiempo de ejecución para la tarea de comprobación de terminación de trabajo. Esta sentencia es usada por un comprobador de seguimiento cuando se especifica OPCOPTS JCCTASK (YES). JCCOPTS se define en el miembro de la biblioteca EQQPARM tal y como se especifica con el parámetro JCCPARM de la sentencia OPCOPTS. Formato JCCOPTS CHKCLASS( A clases SYSOUT ) INCDSN( dsname del archivo de incidencias ) JCCQMAX( 112 tamaño máximo de cola ) JCWAIT( 4 límite de espera ) MAXDELAY( 200 límite de retardo UMAXLINE( 50 número de líneas ) SYSOUTDISP( D Hx R Rx ) ) USYSOUT( JOB ALWAYS NEVER ) Parámetros CHKCLASS(clases SYSOUT|A) Define las clases SYSOUT que usa Tivoli Workload Scheduler for z/OS para comprobar si está disponible SYSOUT. Puede especificar un máximo de 16 clases SYSOUT. Las clases SYSOUT son definidas como una serie de caracteres de clases SYSOUT válidas, un carácter por cada clase de SYSOUT. La selección de SYSOUT también se ve influida por el valor de la palabra clave SYSOUTDISP. | | | | | En un sistema JES2 puede especificarse cualquier clase de SYSOUT. En un sistema JES3, debe definir cualquier clase de SYSOUT que deba ser procesada por la comprobación de terminación de trabajo: v Como una clase de SYSOUT de un grabador externo v Como HOLD=EXTWTR y TYPE=PRINT en la sentencia de inicialización JES3 SYSOUT Si define SYSOUT CLASS como TYPE=DSISO, Tivoli Workload Scheduler for z/OS sólo podrá procesar los conjuntos de datos de SYSTEM SYSOUT.Para JES2 y JES3, el producto de archivado sysout, o la descarga de JES o Capítulo 1. Definición de sentencias de inicialización 81 JCCOPTS | | | cualquier otro proceso que pudiera suprimir la salida antes de que JCC la haya procesado, no pueden utilizar las clases sysout definidas por CHKCLASS. | | | | | | | | | | | | | | | | | Por ejemplo, cuando necesite tener una configuración con el subsistema del almacén de datos y el rastreador con la tarea JCC activa en la misma imagen de sistema z/OS, podrían producirse problemas de compatibilidad si las opciones de la tarea JCC exigen que Tivoli Workload Scheduler for z/OS elimine los conjuntos de datos de la salida sysout después del análisis habitual. Esto es porque la tarea JCC también puede eliminar la copia sysout duplicada creada para el almacén de datos antes de que se haya almacenado con éxito. En esta configuración específica, para evitar este problema y mejorar el rendimiento de JCC (que estaría explorando dos veces los mismos conjuntos de datos sysout) necesita proporcionar una clase JES asociada al destino del rastreador que debe ser usada para el proceso de JCC de los conjuntos de datos sysout, en la opción CHKCLASS de JCCOPTS. El requisito obligatorio es que no debe ser una de las clases sysout especificadas en DSTCLASS de palabra clave de parámetro RCLOPTS. De este modo la tarea JCC nunca procesará los conjuntos de datos de salida especificados para el proceso del almacén de datos. Para obtener más información, consulte DTCLASS. s No más de una tarea JCC puede procesar una clase de SYSOUT en particular. Nota: El valor de la palabra clave es válido incluso si se interrumpe la subtarea de Tivoli Workload Scheduler for z/OS o de JCC. No se cambia hasta que se especifica un valor distinto y se reinicia Tivoli Workload Scheduler for z/OS o la subtarea JCC. INCDSN(dsname del archivo de incidencias) Define el nombre del conjunto de datos de registro de incidencias. Debe ser un conjunto de datos catalogado y secuencial en un dispositivo de almacenamiento de acceso directo (DASD). Varios sistemas Tivoli Workload Scheduler for z/OS y OPC/A pueden usar el mismo conjunto de datos. Las funciones ajenas a IBM Tivoli Workload Scheduler for z/OS pueden actualizar o reubicar el conjunto de datos mientras Tivoli Workload Scheduler for z/OS está ejecutándose. JCCQMAX(tamaño máximo de cola|112) Define el número máximo de registros de sucesos 3P (terminación de trabajo) que puede mantener la cola JCC. El valor predeterminado es 112.Si el valor especificado no es un múltiplo de 16, entonces se redondea al múltiplo de 16 más cercano. Si se emite el mensaje EQQZ035E en un sistema donde se usa la JCC, considere aumentar el valor de JCCQMAX. Consulte el mensaje EQQZ035E en Messages and Codes para obtener más información. JCWAIT(límite de espera|4) Define cuánto tiempo (en segundos) espera la JCC antes de volver a comprobar con JES para ver si está disponible la SYSOUT para un trabajo. La nueva comprobación puede continuar durante el tiempo especificado por la palabra clave MAXDELAY. MAXDELAY(límite de retardo|200) Define cuánto tiempo la JCC debe intentar recuperar la SYSOUT desde JES cuando JES indica que el trabajo no tiene SYSOUT en ninguna de las clases comprobadas por la JCC. El valor MAXDELAY se especifica en segundos. Si se alcanza el límite de retardo, la operación queda establecida con estado de terminada en error. 82 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste JCCOPTS SYSOUTDISP(disposición SYSOUT|) Define la acción que debe realizarse con los conjuntos de datos de SYSOUT que han sido procesado. Puede seleccionar uno de estos valores: Representa un espacio en blanco. No se especifica ninguna disposición. La JCC sólo selecciona SYSOUT no retenidas, y los conjuntos de datos de SYSOUT son eliminados después de ser procesados. D La disposición es suprimir. La JCC sólo selecciona SYSOUT retenidas, y los conjuntos de datos de SYSOUT son eliminados después de ser procesados. Hx La disposición es puesta en cola de nuevo y retenida. La JCC sólo selecciona SYSOUT retenidas, y los conjuntos de datos de SYSOUT se vuelven a poner en la cola para la clase SYSOUT x después de ser procesados. Los conjuntos de datos vueltos a poner en la cola son mantenidos en la nueva clase SYSOUT x. R La disposición es procesar, sin volver a poner en la cola. La JCC sólo selecciona SYSOUT retenidas, y los conjuntos de datos de SYSOUT permanecen en estado retenido después de ser procesados. Rx La disposición es volver a poner en la cola. La JCC sólo selecciona SYSOUT retenidas, y los conjuntos de datos de SYSOUT se vuelven a poner en la cola para la clase SYSOUT x después de ser procesados. Los conjuntos de datos vueltos a poner en la cola no son mantenidos en la nueva clase SYSOUT x. Notas: 1. El valor de la palabra clave es válido incluso si se interrumpe la subtarea de Tivoli Workload Scheduler for z/OS o de JCC. No se cambia hasta que se especifica un valor distinto y se reinicia Tivoli Workload Scheduler for z/OS o la subtarea JCC.Si se usa el almacén de datos, no se realiza puesta en cola nueva. 2. Cuando se especifica en blanco o D, esta palabra clave afecta a las funciones de reinicio y limpieza y debe especificarse la palabra clave RCLOPTS DSTCLASS. Consulte la sentencia RCLOPTS para conocer más detalles. UMAXLINE(número de líneas|50) Define cuántas líneas deben ser exploradas en cada conjunto de datos de SYSOUT de usuario. Puede especificar de 0 a 2 147 328 000 líneas. El valor 0 solicita la exploración de todas las líneas. Si graba vuelcos del sistema a SYSOUT, asegúrese de no explorar los registros de vuelco. USYSOUT(ALWAYS|NEVER|JOB) Solicita la exploración de conjuntos de datos de SYSOUT de usuario: ALWAYS Los conjuntos de datos SYSOUT de usuario se exploran siempre. NEVER Los conjuntos de datos SYSOUT de usuario no se exploran nunca. JOB Los conjuntos de datos de SYSOUT de usuario sólo se exploran si hay una tabla de mensajes específicos para el trabajo. Consulte “Tablas de mensajes de JCC” en la página 317 para obtener más información sobre las tablas de mensajes. Capítulo 1. Definición de sentencias de inicialización 83 JCCOPTS Ejemplos JCCOPTS CHKCLASS(CDEQ) JCWAIT(5) SYSOUTDISP(RA) UMAX(1000) 1 2 3 4 En este ejemplo de una sentencia JCCOPTS: 84 1 La JCC comprueba las clases de SYSOUT C, D, E y Q en busca de conjuntos de datos de SYSOUT. 2 Si se retrasa el proceso de salida de un trabajo, la JCC espera 5 segundos antes de volver a comprobar la cola de salida para la SYSOUT de ese trabajo. 3 Si se encuentra un conjunto de datos de SYSOUT, se procesa según las tablas de mensajes y se vuelve a poner en la cola de la clase A. 4 La JCC explora hasta 1000 líneas en los conjuntos de datos de SYSOUT. IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste JTOPTS JTOPTS Propósito La sentencia JTOPTS define cómo se comportan las operaciones en las estaciones de trabajo y cómo se envían y se les realiza seguimiento. Esta sentencia la usa un controlador o un controlador en reposo. JTOPTS se define en el miembro de la biblioteca EQQPARM tal y como se especifica con el parámetro PARM de la sentencia JCL EXEC. Formato JTOPTS ALEACTION ( 100 límite de acciones de alerta ) 400 frecuencia de creación de copia de seguridad NO BACKUP( ) CONDSUB( NO YES ) CRITJOBS( YES NO ) CURRPLAN( CURRENT NEW ) 100 límite de realimentación del plazo límite DLIMFDBK( ) 50 factor de corrección del plazo límite DSMOOTHING( ) DUAL( NO YES , ) ERRRES( ETT( código de error NO YES ) ) ETTGENSEARCH( YES NO ) ETTNEWDEP( NO YES ) EVELIM( 0 nnnn ) FTWJSUB( YES NO ) HIGHRC( 4 código de retorno sin error máximo ) JOBCHECK( YES NO SAME ) JOBSUBMIT( YES NO ) JTLOGS( 5 nn ) LIMFDBK( 100 límite de realimentación de duración ) MAXJSFILE( 0 tamaño máximo del conjunto de datos de JS NO ) Capítulo 1. Definición de sentencias de inicialización 85 JTOPTS 32767 nnnnnnn MAXOCCNUM( ) 30 días que las instrucciones del operador son nuevas NEWOILIMIT( ) , NOERROR( entrada de código de error ) 1 tiempo de retardo OFFDELAY( ) OPINFOSCOPE( IP ALL ) Y N OPREROUTEDEFAULT( ) OPRESTARTDEFAULT( Y N ) Y N OPSUMWS( ) OUTPUTNODE( FINAL ANY ) OVERCOMMIT( 0 nnnn ) PLANSTART( 6 inicio de período de planificación ) PRTCOMPLETE( YES NO ) QUEUELEN( 5 longitud de la cola ) RECCPCOMPL( YES NO ) SHUTDOWNPOLICY( 0 nnn ) SMOOTHING( 50 factor de corrección , ) STATMSG( CPLOCK EVENTS WSATASK GENSERV ) STATIM( 0 nn ) SUBFAILACTION( R C E RH XC XE XR ) R C E SUPPRESSACTION( SUPPRESSPOLICY( 0 nnn ) TRACK( ALL OPCASUB JOBOPT , ANY READYFIRST READYONLY ) TWSJOBNAME( 86 ) OCCNAME JOBNAME EXTNOCC EXTNAME R ) UX001FAILACTION( IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste ) JTOPTS WSFAILURE( LEAVE ERROR RESTART LEAVE MANUAL , , ) REROUTE IMMED LEAVE IMMED WSOFFLINE( LEAVE ERROR RESTART , , REROUTE ) MANUAL Parámetros ALEACTION (límite de acciones de alerta|100) El límite para llevar a cabo acción de alerta en el plan actual que está activo un periodo de tiempo inesperadamente largo (para obtener más detalles, consulte la palabra clave DURATION en “ALERTS” en la página 10). Si especifica ALEACTION, su valor se utiliza para seleccionar las operaciones para las que se debe emitir una alerta de larga duración. Si no especifica ALEACTION, en su lugar se utilizará el valor LIMFDBK. Los valores para el límite de acciones de alerta están en el rango comprendido entre 100 y 999, o 0 si la acción de alerta se va a tomar en cuanto la operación esté activa más tiempo que su duración estimada. BACKUP (NO|frecuencia de copia de seguridad|400) Tivoli Workload Scheduler for z/OS usa un conjunto de datos principal y alternativo para el plan actual. Tivoli Workload Scheduler for z/OS reorganiza el conjunto de datos del plan actual que se está usando copiándolo en el conjunto de datos inactivo y cambiando después al nuevo conjunto de datos copiado. El valor especificado en la palabra clave BACKUP define si el plan actual debe copiarse automáticamente y determina la frecuencia con la que debe producirse el proceso de copia automática. Especifique una frecuencia de creación de copia de seguridad si desea que Tivoli Workload Scheduler for z/OS realice el proceso de copia automáticamente. El valor de frecuencia de creación de copia de seguridad define cuántos registros deben grabarse en el registro de seguimiento de trabajo antes de realizar un proceso de copia. Tivoli Workload Scheduler for z/OS incluye ambos sucesos con seguimiento registros de auditoría al contar el número de registros grabados al registro de seguimiento de trabajos. Especifique NO si no desea que Tivoli Workload Scheduler for z/OS realice el proceso de copia automáticamente. Si especifica NO, asegúrese de solicitar copias de seguridad a intervalos regulares, dependiendo de la carga de trabajo de su instalación. Puede solicitar que Tivoli Workload Scheduler for z/OS realice un proceso de copia usando el mandato BACKUP o las subrutinas EQQUSIN o EQQUSINB, independientemente del valor especificado en la palabra clave BACKUP. Para obtener más información sobre el mandato BACKUP, consulte Managing the Workload. Para obtener más información sobre las subrutinas EQQUSIN y EQQUSINB, consulte Capítulo 6, “Notificación de sucesos a Tivoli Workload Scheduler for z/OS”, en la página 289. Nota: Si el proceso de copia se realiza automáticamente y se emite una solicitud BACKUP, Tivoli Workload Scheduler for z/OS cuenta el número de registros desde la hora de la copia de seguridad solicitada ante de realizar otra copia automática. Capítulo 1. Definición de sentencias de inicialización 87 JTOPTS La copia de los conjuntos de datos del plan actual también se realiza cuando se inicia o se detiene el controlador, antes y después de la planificación diaria y durante la recuperación de los conjuntos de datos del sistema Tivoli Workload Scheduler for z/OS. Estas copias se realizan independientemente del valor especificado para BACKUP. CONDSUB (YES|NO) Especifique YES si se deben evaluar las dependencias de condiciones definidas en el estado S (iniciado) en cuanto el estado del predecesor condicional pase a S (iniciado) sin esperar el suceso de inicio de trabajo notificado por el componente de comprobación. Especifique NO si las dependencias condicionales definidas en el estado S (iniciado) deben esperar el suceso de inicio de trabajo notificado por el componente de comprobación antes de evaluarse. NO es el valor predeterminado. CRITJOBS(NO|YES) Especifique CRITJOBS(N) para impedir la creación de la tabla de trabajos críticos y el inicio de la tarea del gestor de vías de acceso críticas durante el inicio del controlador, desactivando así la vía de acceso crítica sin restablecer la opción de operación crítica y ejecutando el lote LTP y DP. Considere ejecutarlos con CRITJOBS(N) en las siguientes condiciones: v Durante procedimientos de recuperación. v Cuando la posibilidad de la vía de acceso crítica no encaja con el caso de ejecución de carga de trabajo actual. Para reactivar la posibilidad de vía de acceso crítica, siga los siguientes pasos: 1. Deseche el conjunto de datos de registro EQQJTABL si no está vacío. 2. Reinicie el controlador con CRITJOBS(Y). 3. Envíe un nuevo trabajo de planificación para volver a sincroniza la tabla de trabajos críticos con el plan actual. CURRPLAN (NEW|CURRENT) Esta palabra clave define desde qué conjunto de datos del plan actual se iniciará Tivoli Workload Scheduler for z/OS. El valor predeterminado es que Tivoli Workload Scheduler for z/OS usará el conjunto de datos del plan actual principal (ddname EQQCP1DS) o el conjunto de datos del plan actual alternativo(ddname EQQCP2DS). Si se dañan ambos conjuntos de datos o contienen errores lógicos, si el conjunto de datos EQQCKPT ha sido reubicado o cuando se inicia Tivoli Workload Scheduler for z/OS por primera vez después de la migración, Tivoli Workload Scheduler for z/OS puede iniciarse desde el conjunto de datos del plan actual nuevo (ddname EQQNCPDS). Para hacerlo, especifique CURRPLAN(NEW). El inicio desde el conjunto de datos del plan actual se realizará automáticamente si no se ha creado un plan nuevo mientras Tivoli Workload Scheduler for z/OS estaba inactivo. Use CURRPLAN(NEW) sólo cuando no pueda iniciar Tivoli Workload Scheduler for z/OS usando el conjunto de datos del plan actual principal o alternativo. No use CURRPLAN(NEW) cuando inicie Tivoli Workload Scheduler for z/OS por primera vez con todos los conjuntos de datos vacíos. DLIMFDBK (límite para los comentarios del plazo límite|100) El límite de realimentación del plazo límite. Esta palabra clave determina si el plazo límite estimado en el ciclo de ejecución o la operación de la descripción de la aplicación o se actualiza cuando una aparición de la aplicación alcanza el 88 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste JTOPTS estado de completa. El valor de la palabra clave DLIMFDBK establecido en esta palabra clave sólo se usa si no se establece un valor en la descripción de la aplicación. Los valores de realimentación están comprendidos entre 100 y 999, o 0 si el plazo límite debe actualizarse siempre, independientemente de los valores estimados y reales. Los límites de realimentación para ADL se calculan como sigue: v Límite inferior = ODL * 100/DLF v Límite superior = ODL * DLF/100 Donde: ADL Es el plazo límite real, considerado como los minutos transcurridos entre IA y el tiempo de terminación de la aparición o la operación. ODL El plazo límite anterior para el ciclo de ejecución o la operación (considerado como desplazamiento en minutos desde IA) actualmente almacenados en la base de datos de la descripción de la aplicación. DLF El límite de realimentación del plazo límite. Cuando el límite de realimentación de plazo límite se establece como 100, no se almacena ningún plazo límite estimado en la base de datos de la descripción de la aplicación y no se genera ningún registro de realimentación perdido. Si el plazo límite real está dentro de los límites de realimentación, se aplica un factor de corrección antes de actualizar la descripción de la aplicación. Si el límite de realimentación del plazo límite se establece como 0, la base de datos de descripción de la aplicación se actualiza siempre, a menos que: v También se especifique un límite de realimentación en la aplicación v El factor de corrección no permita el cambio Si el tiempo de terminación se produce antes del tiempo IA, no se actualiza el plazo límite y se genera un registro de realimentación perdida. Cuando se genera la aparición, se almacena en el registro de apariciones un identificador del ciclo de ejecución que genera la la aparición. Este identificador se usa para determinar qué ciclo de ejecución debe actualizarse. Si se modifica la descripción de la aplicación o el comienzo planificado, es posible que el ciclo de ejecución no tenga coincidencias. En este caso, el plazo límite no se actualiza y se genera un informe de registro de realimentación perdido. DSMOOTHING (factor de corrección del plazo límite|50) El factor de corrección del plazo límite. Determina cuánto influye el plazo límite real al plazo límite nuevo estimado para un ciclo de ejecución o una operación en la base de datos de descripción de la aplicación. El factor de corrección sólo se aplica si el plazo límite real está dentro de los límites de realimentación del plazo límite. El valor de la palabra clave DSMOOTHING sólo se usa si no se establece un factor de corrección en la descripción de la aplicación. El factor de corrección está comprendido entre 0 y 999. Un valor 0 significa que el plazo límite no está actualizado, y un valor 100 significa que el plazo límite real sustituye al plazo límite estimado existente. El plazo límite nuevo se calcula del siguiente modo: NDL = ODL + ((ADL - ODL) * DSF/100) Donde: Capítulo 1. Definición de sentencias de inicialización 89 JTOPTS NDL El plazo límite nuevo para el ciclo de ejecución o la operación (considerado como desplazamiento en minutos desde IA) que deben almacenarse en la base de datos de la descripción de la aplicación. ODL El plazo límite anterior para el ciclo de ejecución o la operación (considerado como desplazamiento en minutos desde IA) actualmente almacenados en la base de datos de la descripción de la aplicación. ADL Es el plazo límite real, considerado como los minutos transcurridos entre IA y el tiempo de terminación de la aparición o la operación. DSF El factor de corrección del plazo límite. DUAL (YES|NO) Especifique YES si Tivoli Workload Scheduler for z/OS debe realizar registro cronológico dobles de los conjuntos de datos del registro de seguimiento de trabajos (EQQJTnn). Cuando se inicia, Tivoli Workload Scheduler for z/OS abre conjuntos de datos señalados por los ddnames EQQDLnn en el procedimiento JCL del controlador. El sufijo nn es un número de 01 a 99. El número de conjuntos de datos EQQJTnn y conjuntos de datos EQQDLnn debe ser el mismo. Especifique NO si Tivoli Workload Scheduler for z/OS no debe grabar información de seguimiento de trabajos en conjuntos de datos dobles. NO es el valor predeterminado. ERRRES (código de error,...,código de error) Define una lista de códigos de error que, a efectos de seguimiento de trabajos, provocan el restablecimiento automático de una operación. La operación se restablece al estado A (comienzo) y contiene el mensaje Error, restablecimiento automático en su panel de detalles de operación. Un código de error puede ser: v Un código de retorno de trabajo o de tarea iniciada 4 dígitos (nnnn) v Un código de terminación anómala de sistema (Sxxx) v Un código de terminación anómala de usuario (Uxxx) v Un código definido por IBM Tivoli Workload Scheduler for z/OS Notas: 1. Tivoli Workload Scheduler for z/OS convierte el valor decimal de un código de terminación anómala de usuario a un código de error hexadecimal. Por ejemplo, la terminación anómala de usuario 123 aparece como código de error X'U07B'. 2. El código de error OSEQ es un caso especial y no puede ser restablecido por ERRRES. 3. Con PQ87904 APAR, la lógica ERRRES no se aplica si el código de error es generado por el paso EQQCLEAN, que es un paso insertado en un trabajo reiniciado por la función de reinicio y limpieza. 4. La palabra clave ERRRES es aplicable también a las operaciones que se ejecutan en estaciones de trabajo del agente z-centric. 5. Los únicos códigos de error aceptables son los que aparecen en el Apéndice E de Managing the Workload. Por ejemplo, un usuario somete un trabajo fuera de Tivoli Workload Scheduler for z/OS para el que existe una operación en el plan actual. El trabajo termina de manera anómala con el código S806, el cual se especifica en la lista ERRRES. Tivoli Workload Scheduler for z/OS establece la operación a estado A. Si el usuario vuelve a enviar el trabajo después de corregir el error, Tivoli Workload 90 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste JTOPTS Scheduler for z/OS vuelve a realizar seguimiento automáticamente al trabajo. El estado de la operación cambia de A a S cuando se inicia el trabajo. Tivoli Workload Scheduler for z/OS no puede volver a enviar un operación que ha sido automáticamente restablecida por el proceso ERRRES incluso aunque se especifique SUBMIT=Y para la operación. Por lo tanto, si restablece una operación normalmente enviada por Tivoli Workload Scheduler for z/OS, debe cambiar manualmente el estado a R (lista) usando el diálogo MCP, o mediante PIF si desea que Tivoli Workload Scheduler for z/OS envíe de nuevo el trabajo. Si detiene y vuelve a reiniciar Tivoli Workload Scheduler for z/OS, o si se ha creado un plan diario nuevo, se eliminará la indicación de restablecimiento de error en las operaciones que hayan sido restablecidas y podrán ser enviadas. ETT (YES|NO) Especifique YES si la función de seguimiento desencadenada por sucesos debe estar inicialmente activada al iniciar Tivoli Workload Scheduler for z/OS. Especifique NO si la función ETT no debe estar inicialmente activada. Recuerde que puede activar o desactivar ETT mientras Tivoli Workload Scheduler for z/OS se está ejecutando si usa el diálogo Funciones de servicio. ETTGENSEARCH (NO|YES) Especifique YES si la función de seguimiento desencadenada por sucesos debe buscar el archivo SI primero en busca de una coincidencia exacta o de la mejor coincidencia de aquí en adelante. Esto es así porque los caracteres % o * pueden usarse en la definición de criterios de ETT. Especifique NO si la función de seguimiento desencadenada por sucesos debe buscar el archivo SI sólo en busca de una coincidencia exacta. Use este valor cuando el archivo SI no contenga criterios ETT usando los caracteres % o *. ETTNEWDEP (NO|YES) Determine el tiempo de llegada de entrada utilizado por el planificador al resolver dependencias para las apariciones que: v Se añadan mediante ETT. v Correspondan a las aplicaciones definidas con un ciclo de ejecución que haga referencia al periodo ETTRCY1. En esta condición, para resolver dependencias el planificador utiliza la hora de llegada de entrada asociado al ciclo de ejecución, en lugar de utilizar la hora de llegada de entrada real, que es la hora en la que se añade la aparición. El parámetro ETTNEWDEP afecta a la selección de cualquier sucesor añadido en el plano actual en las condiciones anteriores. Especifique YES si desea que el planificador utilice la hora de llegada de la entrada ETTRCY1 tanto para las apariciones que se añaden al plan actual como a los sucesores de los candidatos, siempre que el sucesor sea una aparición añadida mediante ETT y que corresponda a una aplicación con un ciclo de ejecución que haga referencia a ETTRCY1. Especifique NO si desea que el planificador utilice la hora de llegada de la entrada ETTRCY1 sólo para las apariciones que se añaden al plan actual. En este caso, para los sucesores de los candidatos el planificador utiliza la hora de llegada de entrada actual. EVELIM (nnnn) Esta palabra clave define la frecuencia con la que se emiten mensajes estadísticos relacionados con la palabra clave STATMSG. Capítulo 1. Definición de sentencias de inicialización 91 JTOPTS Sólo se tiene en cuenta si el valor de STATIM es 0, y define el número de sucesos que tarea de gestor de sucesos debe procesar antes de emitir un conjunto nuevo de mensajes. Los valores válidos están comprendidos entre 0 y 9999. Si el valor actual de STATIM es 0 y el valor actual de EVELIM es 0, los mensajes de estadísticas se emiten cada n sucesos, donde n es la mitad del valor BACKUP. El valor de EVELIM puede actualizarse dinámicamente usando el mandato de modificación, /F subsys,EVELIM=nnnn. FTWJSUB (NO|YES) Especifique YES si Tivoli Workload Scheduler for z/OS debe enviar trabajos en agentes distribuidos. Especifique NO si Tivoli Workload Scheduler for z/OS no debe realizar estas funciones automáticamente. La opción para enviar trabajos puede cambiarse mediante el diálogo de Funciones de servicio mientras se está ejecutando Tivoli Workload Scheduler for z/OS. HIGHRC (código de retorno sin error máximo|4) Define el código de error máximo que puede ser generado en un trabajo o tarea iniciada de Tivoli Workload Scheduler for z/OS sin hacer que Tivoli Workload Scheduler for z/OS procese la operación como terminada en error. Nota: Con PQ87904 APAR, la lógica HIGHRC no se aplica si el código de error es generado por el paso EQQCLEAN, que es un paso insertado en un trabajo reiniciado por la función de reinicio y limpieza.En este caso el estado de la operación se establece como finalizado error. JOBCHECK (NO|SAME|YES) La palabra clave JOBCHECK especifica si Tivoli Workload Scheduler for z/OS comprueba la tarjeta de trabajo antes de enviar el trabajo y cómo lo hace. JOBCHECK(YES) significa que Tivoli Workload Scheduler for z/OS comprueba la tarjeta de trabajo sólo para comprobar su validez. Si la tarjeta de trabajo no es válida, el trabajo no se somete. Tivoli Workload Scheduler for z/OS considera válida la tarjeta de trabajo si está en este formato: //nombretrabajo JOB nombretrabajo Consta de 1 a 8 caracteres alfanuméricos o nacionales donde el primer carácter es alfabético o nacional. JOB Debe tener delante y detrás al menos un espacio en blanco. Si la tarjeta de trabajo es válida pero el nombre de trabajo no es el mismo que el nombre de trabajo de la operación actual de Tivoli Workload Scheduler for z/OS, se graba un mensaje de aviso en el registro de mensajes de Tivoli Workload Scheduler for z/OS. JOBCHECK(NO) significa que la tarjeta de trabajo no se comprueba en absoluto. Tivoli Workload Scheduler for z/OS somete el trabajo sin comprobar la tarjeta de trabajo. Nota: JOBCHECK(YES) y JOBCHECK(NO) permiten que Tivoli Workload Scheduler for z/OS envíe un trabajo con un nombre de trabajo que no coincide con el nombre de trabajo de la operación actual. Esto implica que IBM Tivoli Workload Scheduler for z/OS no puede realizar un seguimiento correcto del estado de la operación. Use JOBCHECK(SAME) si necesita realizar seguimiento del estado. 92 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste JTOPTS JOBCHECK(SAME) significa que se comprueba la validez de la tarjeta de trabajo y que el nombre de trabajo sea el mismo que el nombre de trabajo de la operación actual de Tivoli Workload Scheduler for z/OS. El trabajo se somete sólo si tiene una tarjeta de trabajo válida y si el nombre de trabajo coincide con el de la operación actual. Nota: En las operaciones ejecutadas en una estación de trabajo con un identificador de destino definido por el usuario conectado mediante TCP/IP o APPC no se realiza la comprobación. JOBSUBMIT(NO|YES) Especifique YES si Tivoli Workload Scheduler for z/OS debe enviar trabajos, iniciar tareas iniciadas y emitir mensajes WTO (write-to-operator) para operaciones WTO. Especifique NO si Tivoli Workload Scheduler for z/OS no debe realizar estas funciones automáticamente. La opción para enviar trabajos puede cambiarse mediante el diálogo de Funciones de servicio mientras se está ejecutando Tivoli Workload Scheduler for z/OS. JTLOGS(número de registros de JT|5) Especifica el número de registros de seguimiento de trabajos que debe abrir Tivoli Workload Scheduler for z/OS cuando se inicia. El número debe ser un valor comprendido entre 2 y 99. El valor predeterminado es 5. Los conjuntos de datos del registro son identificados por el ddname EQQJTnn en el procedimiento JCL del controlador. Tivoli Workload Scheduler for z/OS intenta para abrir conjuntos de datos que comienzan con EQQJT01 y continúa para el número especificado en la palabra clave JTLOGS. Por ejemplo, si especifica un valor de 3 para JTLOGS, Tivoli Workload Scheduler for z/OS intenta abrir los registros de seguimiento de trabajos EQQJT01, EQQJT02 y EQQJT03. | | LIMFDBK(límite para los comentarios del plazo límite|100) Límite de realimentación de duración. Este parámetro se omite para los trabajos de duplicación. El seguimiento de trabajos de Tivoli Workload Scheduler for z/OS supervisa automáticamente las duraciones reales. Éstas pueden usarse para modificar las duraciones estimadas de la operación en la base de datos de descripción de la aplicación. Tivoli Workload Scheduler for z/OS usa dos factores, el límite de realimentación de duración y la corrección de la duración, para controlar cómo se usan las duraciones reales. El valor LIMFDBK determina si se actualizan las duraciones estimadas en la descripción de la aplicación cuando una aparición de la aplicación alcanza el estado de terminada. El valor de la palabra clave LIMFDBK sólo se usa si no se especifica ningún valor en la descripción de la aplicación. Los valores de realimentación están comprendidos entre 100 y 999, o 0 si la duración debe actualizarse siempre, independientemente de los valores estimados y reales. Los límites de realimientación se calculan del siguiente modo: Capítulo 1. Definición de sentencias de inicialización 93 JTOPTS Límites de realimentación de duración Límite inferior = OD * 100/LF Límite superior = OD * LF/100 donde: OD La duración estimada anterior almacenada actualmente en la base de datos de descripción de la aplicación. LF El límite de realimentación de duración. Si el límite de realimentación de duración se establece como 0, la base de datos de descripción de la aplicación se actualiza siempre, a menos que: v También se especifique un límite de realimentación en la aplicación v El factor de corrección no permita el cambio Si una duración estimada está dentro de los límites de realimentación, se aplica un factor de corrección antes de actualizar la descripción de la aplicación. Consulte la palabra clave SMOOTHING descrita en la página 100. La Tabla 3 muestra ejemplos de cómo funciona el algoritmo de límite de realimentación. Tabla 3. Ejemplos de límite de realimentación Valor LF Resultado 100 No se almacena la duración estimada en la base de datos de descripción de la aplicación. 110 La duración estimada nueva se almacena si la duración real está aproximadamente entre el 90% y el 110% de la duración estimada anterior. 200 La duración estimada nueva se almacena si la duración real está entre la mitad y el doble de la duración estimada anterior. 500 La duración estimada nueva se almacena si la duración real está entre un quinto y cinco veces la duración estimada anterior. 999 La duración estimada nueva se almacena si la duración real está entre un décimo y 10 veces la duración estimada anterior. Nota: El límite de los comentarios utilizado para seleccionar las operaciones para las que se debe emitir una alerta de larga duración es el valor especificado para ALEACTION. Si no se establece ALEACTION, en su lugar se utiliza el valor para LIMFDBK. En este caso, el valor para el límite de retroalimentación que puede especificar opcionalmente en la descripción de la aplicación se omite. MAXJSFILE(NO|tamaño máximo del conjunto de datos de JS|0) Tivoli Workload Scheduler for z/OS usa un conjunto de datos principal y alternativo para el repositorio del JCL. Tivoli Workload Scheduler for z/OS reorganiza el conjunto de datos del repositorio del JCL que se está usando copiándolo en el conjunto de datos inactivo y cambiando después al nuevo conjunto de datos copiado. El valor especificado en la palabra clave MAXJSFILE define si el repositorio del JCL debe copiarse automáticamente y determina la frecuencia con la que debe producirse el proceso de copia automática. 94 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste JTOPTS | | | | | | | | | | | | | | | | | | Especifique un tamaño máximo si desea que Tivoli Workload Scheduler for z/OS copie automáticamente. Este valor también define lo grande que puede hacerse el conjunto de datos del repositorio del JCL actual antes de que sea copiado automáticamente al conjunto de datos alternativo. El tamaño debe indicarse en megabytes (1 MB es igual a 1.024 kilobytes). El valor máximo que se puede especificar es 67 108 864 megabytes. Cualquier valor superior provocará resultados imprevisibles. El valor especificado se convierte en cilindros y se redondea al siguiente número entero. Cualquier valor equivalente a menos de 2 cilindros (que no sea el valor predeterminado) se establece como 2 cilindros. Si no especifica MAXJSFILE o especifica el valor predeterminado 0, Tivoli Workload Scheduler for z/OS realizará una copia después de que los primeros 50 trabajos hayan sido insertados desde que se inició. El tamaño del conjunto de datos (convertido en cilindros) después de la primera copia, más el equivalente de un cilindro, se usa después como el valor para MAXJSFILE. Después de 50 inserciones, Tivoli Workload Scheduler for z/OS comprueba el tamaño del archivo JS usando un algoritmo basado en el high_used_RBA. Si el high_used_RBA es igual o mayor que el valor de MAXJSFILE, se realiza una copia. Especifique NO si no desea que Tivoli Workload Scheduler for z/OS copie automáticamente. Si especifica NO, asegúrese de solicitar copias de seguridad a intervalos regulares, dependiendo de la carga de trabajo de su instalación. Puede solicitar que Tivoli Workload Scheduler for z/OS realice un proceso de copia usando el mandato BACKUP o las subrutinas EQQUSIN o EQQUSINB, independientemente del valor especificado en la palabra clave MAXJSFILE. Para obtener más información sobre el mandato BACKUP, consulte Managing the Workload. Para obtener más información sobre las subrutinas EQQUSIN y EQQUSINB, consulte Capítulo 6, “Notificación de sucesos a Tivoli Workload Scheduler for z/OS”, en la página 289. MAXOCCNUM(nnnnnnn|32767) Tivoli Workload Scheduler for z/OS mantiene un límite superior en el número de apariciones del plan actual. Cuando se alcanza este límite, no se pueden añadir más apariciones, ni con diálogos, ni con la interfaz de programa, ni con seguimiento desencadenado por sucesos ni por la recuperación automática. Si se omite la palabra clave, el límite es de 32767 apariciones. Es aconsejable no establecer el parámetro a un número mayor que el requerido por las necesidades de carga de trabajo reales debido a la sobrecarga aumentada que se produce. Tivoli Workload Scheduler for z/OS puede iniciarse con un plan actual que supere el límite y también hacerse cargo de un plan que supere el límite de la planificación diaria. NEWOILIMIT(días que las instrucciones del operador son nuevas|30) Define el número de días que Tivoli Workload Scheduler for z/OS considera nuevo un registro de instrucción de de operador después de cambiarlo. Se calcula el número de días entre el comienzo planificado de la aparición y la última actualización de la instrucción del operador. Si el resultado es inferior al valor especificado para NEWOILIMIT, o si el comienzo planificado de la aparición es anterior a la última actualización de la instrucción del operador, la instrucción del operador se considera como una instrucción nueva. Las instrucciones de operador nuevas se representan en listas que pueden personalizarse mediante un signo (+) en la columna OI. NOERROR(entrada de código de error,...,entrada de código de error) Define una lista de códigos de error que, a efectos de seguimiento de trabajos, Capítulo 1. Definición de sentencias de inicialización 95 JTOPTS son tratados como códigos de terminación normales. También se pueden especificar códigos de error en la sentencia NOERROR. Consulte “Propósito” en la página 115. Este parámetro sigue la misma regla que el parámetro LIST de la sentencia NOERROR. Para ver una descripción de estas reglas, consulte 116. Nota: No use este parámetro para volver a crear dinámicamente la tabla NOERROR usando un mandato de modificación con la opción NEWNOERR o NOERRMEM. Si necesita volver a crear dinámicamente la tabla NOERROR, use la sentencia NOERROR tal y como se describe en “Propósito” en la página 115. OFFDELAY(tiempo de retardo|1) El parámetro OFFDELAY define, en minutos, el tiempo que Tivoli Workload Scheduler for z/OS retarda las acciones definidas en el parámetro WSOFFLINE cuando una estación de trabajo cambia su estado a fuera de línea. El estado de la estación de trabajo cambia inmediatamente como respuesta a la recepción del suceso fuera de línea por parte del controlador, pero Tivoli Workload Scheduler for z/OS no toma acciones de redireccionamiento o reinicio hasta que transcurre el tiempo especificado para OFFDELAY. Si se recibe un suceso que cambia el estado de la estación de trabajo a disponible durante el tiempo de retardo, no se realizan acciones WSOFFLINE. OFFDELAY sólo se usa cuando una estación de trabajo cambia su estado a fuera de línea, no por una indicación de anomalía. El parámetro OFFDELAY también funciona como tiempo de retardo al configurar una estación de trabajo como fuera de línea durante el inicio del controlador de Tivoli Workload Scheduler for z/OSp. El controlador mantiene inicialmente el estado de la estación de trabajo como era cuando se detuvo el subsistema del controlador. El parámetro OFFDELAY define la cantidad de tiempo que controlador espera que un comprobador de seguimiento establezca comunicación. Si no se realiza durante el tiempo especificado, la estación de trabajo representada por este comprobador de seguimiento se establece como estado OFFLINE. Nota: Si tiene estaciones de trabajo que especifican un identificador de destino definido por el usuario, asegúrese de que la palabra clave OFFDELAY esté configurada lo suficientemente alta como para dejar suficiente tiempo para configurar el destino con estado activo cuando se inicia IBM Tivoli Workload Scheduler for z/OS. OPINFOSCOPE(ALL|IP) Define cómo selecciona Tivoli Workload Scheduler for z/OS una operación cuando se crea un suceso que actualiza el campo USERDATA. El suceso puede crearse mediante un mandato OPINFO TSO, una subrutina EQQUSIN o EQQUSINO o una solicitud API CREATE. Especifique IP (en progreso), que es el valor predeterminado, si Tivoli Workload Scheduler for z/OS debe seleccionar la operación sólo desde operaciones con estado R, A, *, S, I y E. Si hay más de una operación que cumple el criterio de selección Tivoli Workload Scheduler for z/OS elige la operación analizando estas características en el siguiente orden: 1. La operación tiene prioridad 9. 2. Última hora de inicio más temprana. 3. Prioridad 8-1. 96 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste JTOPTS 4. La hora de comienzo planificado especificada para la operación o el comienzo planificado de la aparición si la operación no tiene un comienzo planificado específicamente definido. 5. Estado 'Longest in Ready'. Especifique ALL si Tivoli Workload Scheduler for z/OS también debe comprobar operaciones con estado C y W si se encuentra una operación en progreso que coincida. Se selecciona la operación con la hora de inicio retrasado más temprana. OPREROUTEDEFAULT(N|Y) Define el valor predeterminado para operaciones que tengan un valor en blanco especificado para la opción redireccionable en los detalles de la operación. Especifique N si las operaciones que tengan el redireccionamiento con valor en blanco no son elegibles para ser redireccionadas si la estación de trabajo se queda inactiva. Especifique Y si las operaciones listas deben redireccionarse a la estación de trabajo alternativa si se especifica un valor en blanco y la acción predeterminada de instalación permite redireccionar las operaciones cuando el estado de la estación de trabajo está establecido como anómalo o fuera de línea. La acción predeterminada pues especificarse en: v El diálogo MCP cuando la estación de trabajo se cambia manualmente a fuera de línea o anómala. v El mandato WSSTAT o las subrutinas EQQUSIN o EQQUSINW cuando la estación de trabajo se establece como fuera de línea o anómala. v El segundo valor de las palabras clave WSOFFLINE o WSFAILURE en la sentencia JTOPTS. Este valor predeterminado se aplica a todas las estaciones de trabajo. OPRESTARTDEFAULT(N|Y) Define el valor predeterminado para operaciones que tengan un valor en blanco especificado para la opción reiniciable en los detalles de operación. Especifique N si las operaciones que tienen el reinicio establecido en blanco no son elegibles para reinicio automático si la estación de trabajo se queda inactiva. Especifique Y si las operaciones listas deben redireccionarse a la estación de trabajo alternativa si se especifica un valor en blanco y la acción predeterminada de instalación permite redireccionar las operaciones cuando el estado de la estación de trabajo está establecido como anómalo o fuera de línea. La acción predeterminada pues especificarse en: v El diálogo MCP cuando la estación de trabajo se cambia manualmente a fuera de línea o anómala. v El mandato WSSTAT o las subrutinas EQQUSIN o EQQUSINW cuando la estación de trabajo se establece como fuera de línea o anómala. v El primer valor de las palabras clave WSOFFLINE o WSFAILURE en la sentencia JTOPTS. Este valor predeterminado se aplica a todas las estaciones de trabajo. OPSUMWS(N|Y) Determine qué datos van a recuperarse para Dynamic Workload Console. Especifique Y si desea recuperar los datos de las estadísticas de '. Especifique N si desea que la consulte se realice leyendo todos los registros de operaciones. Capítulo 1. Definición de sentencias de inicialización 97 JTOPTS OUTPUTNODE(ANY|FINAL) Define si Tivoli Workload Scheduler for z/OS debe procesar sucesos A3P (terminación de trabajo JES2) desde cualquier nodo NJE para el que la SYSOUT realiza un archivo de spool o sólo desde el nodo NJE que es el destino final. La palabra clave OUTPUTNODE es válida sólo para entornos JES2. Debido a que se pueden enviar la SYSOUT de trabajos JES2, o partes de la SYSOUT, a varios nodos NJE distintos, puede producirse más de un suceso de terminación de trabajo (A3P) para el mismo trabajo. Además, si se usa la comprobación de terminación de trabajos (JCC), los sucesos también pueden tener distinta información de código de terminación de trabajo dependiendo de la salida enviada a un nodo particular y la comprobación que JCC realice en ese nodo. El estado asignado a la operación depende de qué suceso A3P fue procesado primero por el controlador. Especifique FINAL si usa la JCC para explorar la SYSOUT y los códigos de error establecidos. A continuación, sólo la parte de la SYSOUT que contiene JESYSMSG (anteriormente $SYSMSGS, DSID=4), que ha alcanzado su nodo NJE final, se usa para cambiar el estado de la operación del ordenador correspondiente de estado S (iniciado) a estado C (terminado) o E (terminado en error). FINAL es el valor predeterminado. Especifique ANY si no usa la JCC para explorar la SYSOUT y los códigos de error establecidos. OUTPUTNODE asigna como valor predeterminado FINAL si se especifica RCLEANUP(YES) en la sentencia OPCOPTS. Si la SYSOUT es redireccionada a un nodo NJE no controlado por Tivoli Workload Scheduler for z/OS, se usa el suceso A3P desde el nodo que se está ejecutando para cambiar le estado de la operación correspondiente, independientemente del valor especificado para OUTPUTNODE. OVERCOMMIT(nnnn|0) Define el número de trabajo, de tarea iniciada y de operaciones WTO que pueden iniciarse en las estaciones de trabajo con registro cronológico automático junto con el número especificado como la capacidad del servidor paralelo para la estación de trabajo. Por ejemplo, si la estación de trabajo de una sistema tiene 10 servidores paralelos definidos y OVERCOMMIT especifica 2, entonces pueden iniciarse hasta 12 operaciones para esa estación de trabajo. La estación de trabajo debe usar control en servidores paralelos para que OVERCOMMIT tenga significado. El valor predeterminado es 0, y como máximo 9999. PLANSTART(inicio de período de planificación|6) Define la hora del día, en horas, en la que se inicia el período de planificación diaria. Este valor debe ser igual al valor especificado para PLANHOUR en la sentencia BATCHOPT. PRTCOMPLETE(NO|YES) Especifique YES si Tivoli Workload Scheduler for z/OS debe establecer las operaciones de impresión como terminadas cuando se depura un trabajo por lotes desde el archivo de spool de JES. Especifique NO si Tivoli Workload Scheduler for z/OS no debe establecer las operaciones de impresión como terminadas cuando se depura un trabajo por lotes desde JES. Aquí, las operaciones de impresión se establecen como terminadas sólo con sucesos de final de impresión. 98 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste JTOPTS Considere establecer PRTCOMPLETE como YES si alguno de sus trabajos o tareas iniciadas crean condicionalmente SYSOUT, o si se especifica FREE=CLOSE en la sentencia DD. QUEUELEN(longitud de la cola|5) Define el número máximo de operaciones listas que inicia la subtarea del analizador de estación de trabajo WSA) cada vez que tiene control del recurso del plan actual. El valor predeterminado es 5. Si se especifica un valor inferior a 5, se usa el valor predeterminado. Si se especifica un valor alto para QUEUELEN y hay muchas operaciones listas, esto podría afectar al rendimiento de otras tareas que usan el recurso del plan actual. El valor de QUEUELEN puede actualizarse dinámicamente usando el mandato de modificación, /F subsys,QUELEN=nnnn. RECCPCOMPL(NO|YES) Establezca RECCPCOMPL(N) para evitar un cálculo nuevo de vía de acceso cuando termina una operación de la vía de acceso crítica y la operación siguiente de la misma vía de acceso crítica tiene un predecesor sin terminar. Use el valor predeterminado RECCPCOMPL(Y) para volver a calcular las vías de acceso críticas para todos los desencadenante de nuevo cálculo disponibles. SHUTDOWNPOLICY(nnn|0) El valor SHUTDOWNPOLICY es un porcentaje entre 0 y 999. Permite especificar si Tivoli Workload Scheduler for z/OS debe iniciar una operación cuando queda poco tiempo antes de cerrar una estación de trabajo. Una estación de trabajo debe tener CONTROL ON SERVERS=Y para que esta palabra clave tenga algún efecto. La duración estimada de una operación se multiplica por el porcentaje de SHUTDOWNPOLICY, y el resultado se compara con el tiempo restante en el intervalo de apertura de la estación de trabajo. Si el resultado es superior al tiempo restante en el intervalo de apertura para la estación de trabajo y se especifica un factor distinto de cero, Tivoli Workload Scheduler for z/OS no iniciará la operación. Los siguientes ejemplos muestran cómo se usa SHUTDOWNPOLICY. En estos ejemplos, una operación tiene una duración estimada de 60 minutos, y la estación de trabajo que utiliza se cerrará en 45 minutos. SHUTDOWNPOLICY(0) La operación se inicia independientemente del final del intervalo de apertura de la estación de trabajo actual. SHUTDOWNPOLICY(50) La operación se inicia porque 30 minutos (50% de 60 minutos) es inferior a los 45 minutos restantes en el intervalo de apertura de la estación de trabajo. SHUTDOWNPOLICY(100) La operación no se inicia porque 60 minutos (100% de 60 minutos) es superior al tiempo restante en el intervalo de apertura de la estación de trabajo. SHUTDOWNPOLICY(200) La operación no se inicia porque 120 minutos (200% de 60 minutos) es superior al tiempo restante en el intervalo de apertura de la estación de trabajo. Capítulo 1. Definición de sentencias de inicialización 99 JTOPTS SMOOTHING(factor de corrección|50) El factor de corrección determina cuánto influye la duración real de una operación la duración estimada nueva almacenada en la base de datos de descripción de la aplicación. El factor de corrección sólo se aplica si la duración real está dentro de los límites determinados por la realimentación (consulte la palabra clave LIMFDBK en la página 93). Este parámetro se omite para los trabajos de duplicación. | | Tivoli Workload Scheduler for z/OS usa el valor especificado en la palabra clave SMOOTHING si no se especifica un factor de corrección en los detalles de una operación. El factor de corrección está comprendido entre 0 y 999. Un valor de 0 significa que no se ha actualizado la operación. Un valor de 100 significa que la duración real sustituye a la duración estimada existente de la operación. La duración nueva estimada se calcula del siguiente modo: Duración estimada nueva ND = OD + ((AD − OD) * SF/100) donde: ND La duración estimada nueva que debe almacenarse en la base de datos de descripción de la aplicación. OD La duración estimada anterior almacenada actualmente ahí. AD La duración real. SF El factor de corrección. La Tabla 4 muestra ejemplos de cómo funciona el algoritmo de corrección. Tabla 4. Ejemplos de factores de corrección Factor Resultado 0 No habrá realimentación. 10 La duración estimada nueva será la duración estimada anterior más un décimo de la diferencia entre la duración real y la duración estimada anterior. 50 La duración estimada nueva será la duración estimada anterior más la mitad de la diferencia entre la duración real y la duración estimada anterior. 100 La duración real sustituye a la duración estimada anterior. 999 La duración estimada nueva será la duración estimada anterior más 10 veces la diferencia entre la duración real y la duración estimada anterior. STATMSG(lista de opciones) Define los tipos de mensajes de estado que produce Tivoli Workload Scheduler for z/OS. Puede especificar uno o más de estos valores. 100 CPLOCK La subtarea de gestor de sucesos emite los mensajes EQQE004I y EQQE005I, los cuales describen la frecuencia con las que las distintas tareas tiene conjunto de datos de plan actual referenciado. EVENTS La subtarea de gestor de sucesos emite los mensajes EQQE000I, EQQE006I y EQQE007I, los cuales describen cuántos sucesos han sido procesados y proporcionan estadísticas para los distintos tipos de sucesos. IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste JTOPTS WSATASK La tarea de gestor de sucesos emite los mensajes EQQE008I y EQQE009I, los cuales describen información estadística recogida por la tarea WSA. Todos estos mensajes son emitidos siguiendo el siguiente criterio: v Si se establece STATIM como un valor distinto de 0 (especificando STATIM(n) en la palabra clave JTOPS, o mediante el mandato de modificación /F subsys,STATIM=n), el mensaje se emite aproximadamente cada n minutos si se ha procesado algún suceso. v De lo contrario, si se establece EVELIM como un valor distinto de cero (especificando EVELIM(n) en la palabra clave JTOPS, o mediante el mandato de modificación /F subsys,EVELIM=n), el mensaje se emite aproximadamente cada n sucesos. v De lo contrario, el mensaje se emite aproximadamente una vez cada n sucesos, donde n es la mitad del valor de la palabra clave JTOPTS BACKUP (el valor BACKUP predeterminado es 400). GENSERV La subtarea de servicio general emite los mensajes EQQG010I a EQQG013I, los cuales describen la frecuencia con la que otras tareas han sido procesadas y lo larga que ha sido la cola de servicio general. Tivoli Workload Scheduler for z/OS emite estos mensajes cada 30 minutos, o cada n minutos si el valor de STATIM es distinto de cero (especificando STATIM(n) en la palabra clave JTOPTS, o mediante el mandato de modificación /F subsys,STATIM=n), si se ha procesado alguna solicitud. Para obtener más información sobre cualquiera de estos mensajes, consulte Messages and Codes. STATIM(nn) Define el intervalo de tiempo, en minutos, que debe usarse para emitir los mensajes estadísticos relacionados con la palabra clave STATMSG.Los valores válidos están comprendidos entre 0 y 99. Si se omite esta palabra clave, o si se especifica 0, el intervalo de tiempo no se usa, y los mensajes estadísticos se emiten cada n sucesos, donde n es el valor EVELIM o la mitad del valor BACKUP si ss establece EVELIM como 0. El valor de STATIM puede actualizarse dinámicamente usando el mandato de modificación, /F subsys,STATIM=nn. SUBFAILACTION(C|E|R|RH|XC|XE|XR) Define qué acción debe tomar Tivoli Workload Scheduler for z/OS si se produce una anomalía al recuperar el JCL durante el envío de un trabajo o el inicio de una tarea iniciada. Especifique una de estas acciones: C La operación se establece como terminada. Si se llama a EQQUX001 y devuelve un código de error, entonces se ignora el código de error. E La operación se establece como terminada en error con el código de error OSUF. Si se llama a EQQUX001 y devuelve un código de error, entonces se ignora el código de error. R La operación permanece en la lista de preparados con estado R (preparada) y estado ampliado E (error). Si la salida de iniciación de operación (EQQUX009) informa de la anomalía, la operación Capítulo 1. Definición de sentencias de inicialización 101 JTOPTS permanece en la lista de preparados con estado S (iniciada) y estado ampliado E (error). Si se llama a EQQUX001 y devuelve un código de error, entonces se ignora el código de error. RH Ésta actúa del mismo modo que R, a menos que se llame a EQQUX001 y devuelva un código de error distinto de '0000', en cuyo caso la operación se establece como preparada y se deja en retención manual. XC Ésta actúa del mismo modo que C, a menos que se llame a EQQUX001 y devuelva un código de error distinto de '0000', en cuyo caso la operación termina en error con el código de error devuelto por la salida del usuario. XE Ésta actúa del mismo modo que E, a menos que se llame a EQQUX001 y devuelva un código de error distinto de '0000', en cuyo caso la operación termina en error con el código de error devuelto por la salida del usuario. XR Ésta actúa del mismo modo que R, a menos que se llame a EQQUX001 y devuelva un código de error distinto de '0000', en cuyo caso la operación termina en error con el código de error devuelto por la salida del usuario. SUPPRESSACTION(C|E|R) Define qué acción debe realizar Tivoli Workload Scheduler for z/OS si una operación tipo Cancelar si es demasiado tarde dependiente de la hora se produce tarde. Especifique una de estas acciones: C La operación se establece como terminada. E La operación se establece como terminada en error con el código de error OSUP. R La operación permanece en la lista de preparados con estado R (preparada) y estado ampliado L (tarde). No todas las acciones de supresión son aplicables a las operaciones definidas en estaciones de trabajo no tolerantes a errores en un entorno global: para operaciones con la opción de script centralizado, las acciones de supresión aplicables son C, E y R; para el resto de operaciones definidas en estaciones de trabajo no tolerantes a errores, la acción de supresión aplicable es sólo R. Si se especifica un valor diferente, se usa el valor predeterminado R para estas operaciones. Notas: 1. Para operaciones ejecutadas en estaciones de trabajo no tolerantes a errores el estado E sólo se permite para scripts centralizados. Sin embargo, para el controlador y el agente no tolerante a errores el estado no coincide hasta que se ejecuta un trabajo DP por lotes (renovación de Symphony, ampliación de CP, nueva planificación de CP). 2. Tivoli Workload Scheduler for z/OS considera el almacenamiento intermedio de tiempo creado por la palabra clave SUPPRESSPOLICY al decidir si una operación dependiente de la hora llega tarde. Nota: SUPPRESSPOLICY(nnn|0) Especifica cómo debe controlar Tivoli Workload Scheduler for z/OS las operaciones dependientes de la hora con la opción Cancelar si es demasiado tarde. Puede usar SUPPRESSPOLICY para crear un almacenamiento intermedio 102 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste JTOPTS de comienzo planificado para estas operaciones dependientes de la hora en lugar de una hora de comienzo planificado específico. El valor SUPPRESSPOLICY es un porcentaje entre 0 y 999. Un valor de 0 significa que Tivoli Workload Scheduler for z/OS no intentará iniciar la operación si ha pasado su hora de comienzo planificado. Si especifica un valor distinto de cero, Tivoli Workload Scheduler for z/OS multiplica la duración estimada de la operación por este porcentaje. Si el valor resultante está dentro del tiempo estante hasta la hora límite de la operación, se iniciará la operación. De lo contrario, la operación será considerada como tarde y no será iniciada por Tivoli Workload Scheduler for z/OS. Los siguientes ejemplos muestran cómo se usa SUPPRESSPOLICY. En estos ejemplos, una operación está preparada. La hora de comienzo planificado de la operación pasó hace 15 minutos, y su hora límite caducará en 45 minutos. La operación tiene una duración estimada 60 minutos. SUPPRESSPOLICY(0) La operación es considerada como tarde porque ha pasado la hora de comienzo planificado. Se realizará la acción especificada en la palabra clave SUPPRESSACTION. SUPPRESSPOLICY(50) La operación se inicia porque 30 minutos (50% de 60 minutos) es inferior a los 45 minutos restantes hasta la hora límite. SUPPRESSPOLICY(100) La operación se considera como tarde porque 60 minutos (100% de 60 minutos) es superior al tiempo restante de la hora límite. Se realizará la acción especificada en la palabra clave SUPPRESSACTION. SUPPRESSPOLICY(200) La operación se considera como tarde porque 120 minutos (200% de 60 minutos) es superior al tiempo restante de la hora límite. Se realizará la acción especificada en la palabra clave SUPPRESSACTION. La opción Cancelar si es demasiado tarde en operaciones definidas en estaciones de trabajo no tolerantes a errores sin opción de script centralizado y que no usan recursos especiales no es manejada directamente por el controlador, sino que es almacenada en el archivo Symphony como "hora de finalización", consulte la publicación Tivoli Workload Scheduler Reference Guide. El valor 'hora de finalización' se establece mediante SUPPRESSPOLICY con el mismo algoritmo que para las otras operaciones si la hora de finalización de la operación esperada es anterior a la hora límite, de lo contrario se establece a la hora de comienzo planificado de la operación más un minuto. TRACK(OPCASUB|JOBOPT|ALL, READYFIRST|READYONLY|ANY) El parámetro TRACK contiene dos valores de palabra clave: v El primer valor especifica a qué trabajos o tareas iniciadas realiza seguimiento Tivoli Workload Scheduler for z/OS. Si se realiza seguimiento a un trabajo, significa que los sucesos para ese trabajo hacen que el plan actual se actualice. El estado de la operación en el plan actual que representa el trabajo es actualizado por sucesos como inicio de trabajo y terminación de trabajo. Por ejemplo, cuando un trabajo termina de ejecutarse en un sistema (estación de trabajo de sistema), el estado de la operación correspondiente del plan actual cambia de S (iniciada) a C (terminada). Capítulo 1. Definición de sentencias de inicialización 103 JTOPTS Si usa seguimiento desencadenado por sucesos con sustitución de nombre de trabajo (sucesos tipo J con JR=Y), ambos operandos del parámetro TRACK son ignorados para trabajos enviados desde fuera de Tivoli Workload Scheduler for z/OS. Siempre se realiza seguimiento a dichos trabajos. Especifique OPCASUB cuando los trabajos planificados y tareas iniciadas por Tivoli Workload Scheduler for z/OS sean enviadas por Tivoli Workload Scheduler for z/OS; es decir, cuando estén todos definidos con la opción SUBMIT establecida como YES. Este es el método recomendado para el envío de trabajos. Tivoli Workload Scheduler for z/OS realiza seguimiento al trabajo enviado por sí mismo; no se realiza seguimiento al trabajo enviado fuera de Tivoli Workload Scheduler for z/OS, ni siquiera cuando corresponde a una operación definida en el plan actual. Especifique JOBOPT cuando algunos de los trabajos planificados por Tivoli Workload Scheduler for z/OS sean enviados por Tivoli Workload Scheduler for z/OS y algunos sean enviados fuera de Tivoli Workload Scheduler for z/OS, pero siempre sabe con antelación cuáles son enviados por cada método. Debe asegurarse de que: – Los trabajos enviados por Tivoli Workload Scheduler for z/OS tengan su opción SUBMIT establecida como YES, y de que estos trabajos no sean enviados fuera de Tivoli Workload Scheduler for z/OS. – Los trabajos enviados fuera de Tivoli Workload Scheduler for z/OS tengan su opción SUBMIT establecida como NO. Cuando se usa JOBOPT, Tivoli Workload Scheduler for z/OS realiza seguimiento a los trabajos enviados por él mismo, y los trabajos enviados fuera de Tivoli Workload Scheduler for z/OS pero definidos con su opción SUBMIT establecida como NO. JOBOPT hace que Tivoli Workload Scheduler for z/OS realice seguimiento a trabajos donde el modo de envío coincide correctamente con la opción SUBMIT para el trabajo. Si define un trabajo con la opción SUBMIT establecida como YES pero el trabajo es enviado fuera de Tivoli Workload Scheduler for z/OS, no se realiza seguimiento al trabajo. Especifique ALL cuando no sepa con antelación si los trabajos planificados por Tivoli Workload Scheduler for z/OS van a ser enviados por Tivoli Workload Scheduler for z/OS o fuera de Tivoli Workload Scheduler for z/OS. Se realiza seguimiento a todos los trabajos planificados por Tivoli Workload Scheduler for z/OS, independientemente de cómo se someten o qué opción SUBMIT de trabajo establecida. v El segundo valor de la palabra clave determina cómo selecciona Tivoli Workload Scheduler for z/OS la operación coincidente cuando se somete un trabajo o una tarea iniciada fuera de Tivoli Workload Scheduler for z/OS. El producto usa este valor sólo cuando se especifica JOBOPT o ALL para el primer valor de la palabra clave. Especifique READYFIRST para seleccionar la operación preparada con la hora de inicio retrasado más temprana. Si no se encuentra una operación preparada, Tivoli Workload Scheduler for z/OS selecciona la operación que está en espera con la hora de inicio retrasado más temprana. Tivoli Workload Scheduler for z/OS establece el estado de esta operación como E (terminada en error) con el código de error OSEQ. Especifique READYONLY para seleccionar la operación preparada con la hora de inicio retrasado más temprana. Si no se encuentra una operación preparada, Tivoli Workload Scheduler for z/OS no realiza seguimiento al trabajo o tarea iniciada. 104 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste JTOPTS Especifique ANY para seleccionar la operación con la hora de inicio retrasado más temprana, la cual está en estado de espera o preparada. ANY es el valor predeterminado. TWSJOBNAME(EXTNAME|EXTNOCC|JOBNAME|OCCNAME) Define el criterio usado para generar el nombre de trabajo en el archivo Symphony. Si define OCCNAME, el nombre del trabajo del archivo Symphony se forma según uno de estos formatos: X_Num_ApplicationName Cuando se crea el trabajo. X_Num_Ext_ApplicationName Cuando se suprime el trabajo y se vuelve a crear en el plan actual. donde: X Puede ser uno de los siguientes valores: v J, para las operaciones normales v P, para los trabajos que representan predecesores pendientes v R, para los trabajos de recuperación Num El número de la operación. Ext Un número decimal secuencial que aumenta cada vez que una operación se suprime y se vuelve a crear. ApplicationName El nombre de la aparición a la que pertenece la operación. Si define EXTNAME, EXTNOCC o JOBNAME, el nombre del trabajo del archivo Symphony se forma según uno de estos formatos: X_Num_JobInfo Cuando se crea el trabajo. X_Num_Ext_JobInfo Cuando se suprime el trabajo y se vuelve a crear en el plan actual. donde: X Puede ser uno de los siguientes valores: v J, para las operaciones normales v P, para los trabajos que representan predecesores pendientes v R, para los trabajos de recuperación Para trabajos que representan predecesores pendiente, el nombre de trabajo es en todos los casos generado siguiendo el criterio OCCNAME. Esto es así porque, en el caso de los predecesores pendientes, el plan actual no contiene la información requerida (exceptuando el nombre de la aparición) para compilar el nombre de Symphony según los otros criterios. Num El número de la operación. Ext El valor hexadecimal de un número secuencial que aumenta cada vez que se suprime y vuelve a crear una operación. JobInfo Depende del criterio elegido: Para EXTNAME JobInfo se completa con los primeros 32 caracteres del nombre de trabajo ampliado asociado a ese trabajo (si existe) o con el nombre de trabajo de 8 caracteres (si no existe el nombre ampliado). Capítulo 1. Definición de sentencias de inicialización 105 JTOPTS Recuerde que el nombre de trabajo ampliado, además de ser definido en la base de datos, también debe existir en el plan actual. Para EXTNOCC JobInfo se completa con los primeros 32 caracteres del nombre de trabajo ampliado asociado a ese trabajo (si existe) o con el nombre de la aplicación (si no existe el nombre ampliado). Recuerde que el nombre de trabajo ampliado, además de ser definido en la base de datos, también debe existir en el plan actual. Para JOBNAME JobInfo se completa con el nombre de trabajo de 8 caracteres. El criterio usado para generar un nombre de trabajo de Tivoli Workload Scheduler se mantendrá durante toda la vida del trabajo. Para elegir el criterio EXTNAME, EXTNOCC o JOBNAME, el conjunto de datos EQQTWSOU debe tener una longitud de registro de 160 bytes. Antes de usar cualquiera de las palabras clave citadas arriba, DEBE migrar el conjunto de datos EQQTWSOU. Está disponible EQQMTWSO de ejemplo para migrar este conjunto de datos de 120 a 160 bytes. Limitaciones al usar los criterios EXTNAME y EXTNOCC: v El nombre de trabajo del archivo symphony no puede contener sólo caracteres alfanuméricos, guiones y subrayados. El resto de caracteres aceptados para el nombre de trabajo ampliado se convierten en guiones. Recuerde que existe una limitación similar con JOBNAME: al definir miembros de conjuntos de datos particionados (como el script o las bibliotecas de trabajos), pueden usarse caracteres nacionales, pero son convertidos a guiones en el archivo symphony. v El nombre de trabajo del archivo symphony debe estar en mayúsculas. Todos los caracteres en minúsculas del nombre ampliado son convertidos automáticamente a mayúsculas por Tivoli Workload Scheduler for z/OS. Nota: Usar el nombre de trabajo (o el nombre ampliado como parte del nombre de trabajo) en el archivo symphony implica que se convierte en una clave para identificar el trabajo. Esto también significa que el nombre ampliado/nombre de trabajo se usa como clave para direccionar todos los sucesos dirigidos a los agentes. Por esta razón, sea consciente de los siguientes hechos para las operaciones incluidas en el archivo symphony: v No se puede editar el nombre ampliado para operaciones creadas cuando la palabra clave TWSJOBNAME fue establecida como EXTNAME o EXTNOCC v No se puede editar el nombre de trabajo para operaciones creadas cuando la palabra clave TWSJOBNAME fue establecida como EXTNAME o JOBNAME. UX001FAILACTION(R) Esta palabra clave se especifica cuando está involucrada la salida EQQUX001. SI se llama a EQQUX001 y devuelve un código de error distinto de 0000, las operaciones permanecen en la lista de preparados con estado ampliado E. El único valor de UX001FAILACTION es R. Las palabras clave UX001FAILACTION y SUBFAILACTION(XR/XE) son exclusivas. WSFAILURE(ERROR|RESTART|LEAVE, REROUTE|LEAVE, IMMED|MANUAL) Define las acciones que deben realizarse cuando se produce una anomalía en una estación de trabajo. Una estación de trabajo queda establecida con estado 106 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste JTOPTS anómalo cuando no hay comunicación con el sistema z/OS o si se establece manualmente en los diálogos de Tivoli Workload Scheduler for z/OS. Las estaciones de trabajo que especifican un identificador de destino definido por el usuario pueden tener un estado anómalo del que informa el mandato WSSTAT o las subrutinas EQQUSIN o EQQUSINW. El parámetro WSFAILURE contiene tres valores de palabra clave: v La primera palabra clave define las acciones de reinicio que deben realizarse cuando falla una estación de trabajo y la operación es reiniciable. Especifique ERROR para establecer las operaciones iniciadas como terminadas en error. El código de error será OSSI, OSSQ, OSSS o OSSC. Las operaciones cuyo código de error es OSSS tienen un código de paso de OSYS. Especifique RESTART para restablecer inmediatamente las operaciones iniciadas en esta estación de trabajo como preparadas. Especifique LEAVE para dejar las operaciones iniciadas en una estación de trabajo anómala como iniciadas; éste es el valor predeterminado. Notas: 1. Si establece la opción reiniciable de una operación como NO, no se procesa la operación. Permanece como iniciada. 2. Recuerde esta nota si usa un controlador en reposo ejecutándose con el parámetro TAKEOVER(HOSTFAIL) en la sentencia XCFOPTS. Si ha seleccionado las opciones WSFAILURE(RESTART,REROUTE,IMMED) y el controlador termina de manera anómala o se cancela, mientras la partición lógica (LPAR) en la que se está ejecutando el controlador permanece activa, los trabajos pueden enviarse de nuevo aunque estén ejecutándose en ese momento, lo cual provoca que el mismo trabajo se ejecute dos veces. | | | | | 3. Para las estaciones de trabajo de motores remotos, esta palabra clave soporta sólo el valor LEAVE. Si especifica cualquier otro valor, se fuerza en LEAVE. v El segundo valor de la palabra clave define acciones de redireccionamiento para situaciones de anomalía de la estación de trabajo. Especifique REROUTE para direccionar operaciones cuya opción redireccionable sea YES a la estación de trabajo alternativa. Especifique LEAVE para dejar que las operaciones sean planificadas en la estación de trabajo original; este es el valor predeterminado. En estas operaciones no se produce redireccionamiento. Para las estaciones de trabajo de motores remotos, esta palabra clave soporta sólo el valor LEAVE. Si especifica cualquier otro valor, se fuerza en LEAVE. v El tercer valor de la palabra clave define la acción que debe realizarse cuando una estación vuelve a estar activa después de una situación de anomalía. Especifique IMMED para establecer automáticamente el estado de la estación de trabajo como disponible y retirar inmediatamente cualquier redireccionamiento cuando un suceso indique que la estación de trabajo está operativa. Especifique MANUAL para indicar que el estado de la estación de trabajo debe cambiarse manualmente cuando se recibe una indicación de estación de trabajo disponible; éste es el valor predeterminado. IBM Tivoli Workload Scheduler for z/OS emitirá un mensaje MLOG para informar al operador de que se ha recibido el suceso. WSOFFLINE(ERROR|RESTART|LEAVE, REROUTE|LEAVE, MANUAL|IMMED) Define las acciones que se deben llevar a cabo cuando se produce una situación fuera de línea de la estación de trabajo, lo cual significa que el controlador no se puede comunicar con el comprobador de seguimiento en el destino definido para la estación de trabajo. Esto puede suceder porque Capítulo 1. Definición de sentencias de inicialización 107 JTOPTS todavía no se ha iniciado el comprobador de seguimiento o ha terminado de manera anómala, o porque el controlador no ha recibido un suceso identificador desde el destino durante dos intervalos de pulso consecutivos. Los intervalos de pulso se especifican con la palabra clave PULSE de ROUTOPTS. Las estaciones de trabajo que especifican un identificador de destino definido por el usuario se establecen como fuera de línea cuando se inicia Tivoli Workload Scheduler for z/OS. El estado fuera de línea de estas estaciones de trabajo también puede ser mostrado por el mandato WSSTAT o las subrutinas EQQUSIN o EQQUSINW. El parámetro WSOFFLINE contiene tres valores de palabra clave: v El primer valor de la palabra clave define las acciones de reinicio para una estación de trabajo cuyo estado ha cambiado a fuera de línea. Especifique ERROR para establecer las operaciones iniciadas, cuya opción reiniciable es YES, como terminadas en error. El código de error será OFSI, OFSQ, OFSS o OFSC. Las operaciones cuyo código de error es OFSS tienen un código de paso de OFFL. Especifique RESTART para restablecer inmediatamente las operaciones iniciadas en esta estación de trabajo como preparadas. Especifique LEAVE para dejar las operaciones iniciadas en una estación de trabajo fuera de línea como iniciadas; éste es el valor predeterminado. Notas: 1. Si establece la opción reiniciable de una operación como NO, no se procesa la operación. Permanece como iniciada. 2. Recuerde esta nota si usa un controlador en reposo ejecutándose con el parámetro TAKEOVER(HOSTFAIL) en la sentencia XCFOPTS. Si ha seleccionado las opciones WSOFFLINE(RESTART,REROUTE,IMMED) y el controlador termina de manera anómala o se cancela, mientras la partición lógica (LPAR) en la que se está ejecutando el controlador permanece activa, los trabajos pueden enviarse de nuevo aunque estén ejecutándose en ese momento, lo cual provoca que el mismo trabajo se ejecute dos veces. 3. Para las estaciones de trabajo de motores remotos, esta palabra clave soporta sólo el valor LEAVE. Si especifica cualquier otro valor, se fuerza en LEAVE. v El segundo valor de la palabra clave define acciones de redireccionamiento para situaciones de estación de trabajo fuera de línea. Especifique REROUTE para direccionar operaciones cuya opción redireccionable sea YES a la estación de trabajo alternativa. Especifique LEAVE para dejar que las operaciones sean planificadas en la estación de trabajo original; este es el valor predeterminado. En estas operaciones no se produce redireccionamiento. Para las estaciones de trabajo de motores remotos, esta palabra clave soporta sólo el valor LEAVE. Si especifica cualquier otro valor, se fuerza en LEAVE. v El tercer valor de la palabra clave define la acción que debe realizarse cuando una estación vuelve a estar activa. Especifique MANUAL para indicar que el estado de la estación de trabajo debe cambiarse manualmente cuando se recibe una indicación de estación de trabajo disponible;. Tivoli Workload Scheduler for z/OS emitirá un mensaje MLOG para informar al operador de que se ha recibido el suceso.Especifique IMMED para establecer automáticamente el estado de la estación de trabajo como disponible y retirar inmediatamente cualquier redireccionamiento cuando un suceso indique que la estación de trabajo está operativa; éste es el valor predeterminado. | | | | | 108 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste JTOPTS Ejemplos JTOPTS BACKUP(1000) ETT(YES) HIGHRC(0) JOBCHECK(SAME) NOERROR(U001,ABC123.*.*.0016,*.P1.S1.U*) SHUTDOWNPOLICY(50) STATIM(25) STATMSG(CPLOCK,EVENTS,WSTASK) SUBFAILACTION(E) SUPPRESSACTION(C) SUPPRESSPOLICY(50) TRACK(JOBOPT) WSFAILURE(LEAVE,LEAVE,IMMED) WSOFFLINE(LEAVE,LEAVE,IMMED) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 En este ejemplo de una sentencia JTOPTS: 1 Siempre que el número de registros del conjunto de datos del plan actual llega a 1000, el conjunto de datos se copia al registro de seguimiento de trabajos. 2 La función de seguimiento desencadenado por sucesos está inicialmente activa al iniciar Tivoli Workload Scheduler for z/OS. 3 Si el código de terminación de operación es mayor que 0, el trabajo o tarea iniciada se trata como terminado en error. 4 Tivoli Workload Scheduler for z/OS somete trabajos sólo si tienen una tarjeta de trabajo válida donde el nombre de trabajo coincide con le nombre de operación. 5 Los trabajos o tareas iniciadas con código de terminación anómala de usuario U001 no son considerados erróneos. La operación ABC123 no se considera errónea si tiene un código de error 0016. Los códigos de terminación anómala de trabajos o tareas iniciadas en los pasos P1 del procedimiento y paso S1 no son considerados como error. 6 Una operación se inicia si el tiempo restante en el intervalo de apertura de la estación de trabajo no es inferior al 50% de la duración estimada de la operación. 7 El mensaje de estadísticas se emite aproximadamente cada 25 minutos. 8 La subtarea de gestor de sucesos emite mensajes que muestran: v La frecuencia con la que las distintas tareas han hecho referencia al conjunto de datos del plan actual v Qué tareas han actualizado el plan actual v Cuántos sucesos han sido procesados v Estadísticas recopiladas por la tarea WSA 9 Tivoli Workload Scheduler for z/OS establece una operación como terminada en error si se produce una anomalía durante el envío de un trabajo o el inicio de una tarea iniciada. 10 Si una operación dependiente de la hora se produce tarde (después que el almacenamiento intermedio SUPPRESSPOLICY haya caducado) y se establece la opción Cancelar si es demasiado tarde como Y para esta operación, la operación se establece como terminada. 11 En este ejemplo, se inicia una operación dependiente de la hora con la Capítulo 1. Definición de sentencias de inicialización 109 JTOPTS opción Cancelar si es demasiado tarde si el tiempo restante hasta su hora límite no es inferior al 50% de la duración estimada de la operación. 110 12 Tivoli Workload Scheduler for z/OS realiza seguimiento a trabajos sólo si el modo de envío coincide con la opción JOB SUBMIT en la descripción de aplicación. 13 Si el estado de una estación de trabajo se cambia a FAILED, las operaciones iniciadas en la estación de trabajo quedan en estado iniciado. Las operaciones preparadas no son redireccionadas a una estación de trabajo alternativa. Serán planificadas en la estación de trabajo original cuando vuelva a estar activa de nuevo. Cuando la estación de trabajo vuelve a estar activa de nuevo, pasa a estar disponible inmediatamente. 14 Si se cambia el estado de una estación de trabajo a OFFLINE, las operaciones iniciadas en la estación de trabajo quedan en estado iniciado. Las operaciones preparadas no son redireccionadas a una estación de trabajo alternativa. Serán planificadas en la estación de trabajo original cuando vuelva a estar activa de nuevo. Cuando la estación de trabajo vuelve a estar activa de nuevo, pasa a estar disponible inmediatamente. IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste MONOPTS MONOPTS Propósito La sentencia MONOPTS define las opciones necesarias para que IBM Tivoli Workload Scheduler for z/OS funcione con IBM Tivoli Monitoring. Esta sentencia la usa un controlador. La sentencia MONOPTS define la información necesaria para activar una actividad de IBM Tivoli Monitoring. Si se proporciona esta sentencia, el controlador inicia la tarea de supervisión usada para enviar mensajes a la interfaz de cliente de Tivoli Enterprise Portal. MONOPTS se define en el miembro de la biblioteca EQQPARM tal y como se especifica con el parámetro PARM de la sentencia JCL EXEC. Definir esta sentencia requiere la definición de un segmento OMVS para el identificador de usuario del controlador. Formato MONOPTS BULKDISC( MONHOSTNAME( NO YES nombrehost dirección IP LOCPORT( ) ) puerto ) MONPORT( 7500 puerto ) Parámetros BULKDISC YES|NO) Describe la política de descubrimiento masivo. Los valores válidos son YES y NO, el valor predeterminado es NO. NO IBM Tivoli Workload Scheduler for z/OS no realiza un descubrimiento automático. Un descubrimiento sólo es posible usando manualmente el mandato TSO. YES Cada vez que se solicita una acción de planificación diaria se realiza un descubrimiento masivo. También se puede solicitar un descubrimiento manualmente. LOCPORT(puerto) Este parámetro es opcional e indica el número de puerto al que se enlazará el controlador para la comunicación TCP/IP con el Universal Agent. Este parámetro debe especificarse sólo si se configura el número de puerto en el metarchivo, de lo contrario el controlador puede usar cualquier número de puerto. MONHOSTNAME(nombrehost|dirección IP) Especifica el nombre de host o la dirección IP de la aplicación de supervisión remota. Para la integración con IBM Tivoli Monitoring, éste es el nombre de host del sistema donde se instala el componente Tivoli Universal Agent de IBM Tivoli Monitoring. Este parámetro es obligatorio. MONPORT(valor|7500) Este parámetro identifica el número de puerto de la aplicación de supervisión remota. Es el número de puerto usado por el componente Tivoli Universal Capítulo 1. Definición de sentencias de inicialización 111 MONOPTS Agent de IBM Tivoli Monitoring. Si no se especifica, se usará el valor predeterminado 7500. El valor especificado aquí debe corresponder al valor definido en Tivoli Universal Agent. Nota: Ya no se da soporte a CONNTIMEOUT y LOCHOSTNAME. Si los especifica, el controlador emite un mensaje de aviso notificando que se usarán los parámetros CONNTIMEOUT y HOSTNAME de la sentencia TCPOPTS. Ejemplos MONOPTS MONHOSTNAME(’9.122.227.72’) MONPORT(7500) LOCHOSTNAME(’9.87.130.44’) BULKDISC(YES) CONNTIMEOUT(10) 1 2 3 En este ejemplo de sentencia MONOPTS: 112 1 Es la dirección IP de Tivoli Universal Agent (aplicación de supervisión remota). 2 Es el número de puerto de Tivoli Universal Agent. 3 Se iniciará automáticamente un descubrimiento automático de los recursos supervisados en cada acción de planificación (ampliación, nueva planificación). IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste MONPOL MONPOL Propósito La sentencia MONPOL define la política de supervisión basada en qué operaciones de IBM Tivoli Workload Scheduler for z/OS son supervisadas automáticamente. Las operaciones que cumplen la política especificada, junto con todas las operaciones marcadas manualmente usando EXTERNAL MONITOR=YES, constituyen el conjunto actual de operaciones supervisadas. Pueden especificarse uno o más valores para la sentencia MONPOL. Esta sentencia sólo se usa junto con la sentencia MONOPTS (usada por IBM Tivoli Monitoring) o cuando se ha especificado EXTMON = YES en la sentencia OPCOPTS (usada por Tivoli Business Systems Manager). Formato MONPOL OPERATION( ERROR CRITICAL LATE DURATION MANUAL ) Parámetros (OPERATION CRITICAL||ERROR|LATE|DURATION|MANUAL) Define los criterios usados para seleccionar las operaciones que deben ser supervisadas por IBM Tivoli Monitoring o por Tivoli Business Systems Manager CRITICAL El planificador supervisará las operaciones que son: v Elegibles para asistencia WLM. v Incluidas en una red crítica. En concreto, cuando el planificador vuelve a calcular una vía de acceso crítica o cambia el nivel de riesgo de una operación, envía un suceso a TivoliTivoli Universal Agent. v Añadida a la lista de host. ERROR Se supervisarán todas las operaciones terminadas en error. Éste es el valor predeterminado. LATE Se supervisarán todas las operaciones que se producen tarde. Una operación es considerada como tarde si alcanza su última hora de inicio y no se ha iniciado, terminado o suprimido. DURATION Se supervisarán todas las operaciones que sobrepasen su tiempo de duración estimada. MANUAL Sólo se seleccionarán los trabajosos marcados explícitamente por el usuario como "supervisada". Este valor excluye el resto de valores especificados. Notas: 1. La sentencia MONPOL no es retroactiva. Basándose en la política especificada, las operaciones son seleccionadas para ser supervisadas sólo cuando se produce el siguiente cambio de estado cumpliendo los criterios Capítulo 1. Definición de sentencias de inicialización 113 MONPOL de MONPOL. Si una operación está en uno de loas estados especificados antes de que MONPOL esté en vigor, no será supervisada. 2. Cuando se ha promovido una operación a "supervisada" para una condición LATE o DURATION, seguirá siendo supervisada aunque se cambie posteriormente el distintivo EXTERNAL MONITORING (supervisión externa) para la operación a NO. Ejemplos MONPOL OPERATION (CRITICAL LATE DURATION) 1 En este ejemplo de sentencia MONPOL: 1 114 Las operaciones elegibles para asistencia WLM, incluidos en una red crítica y añadidos a la lista caliente, serán seleccionados automáticamente para ser supervisados. IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste NOERROR NOERROR Propósito La sentencia NOERROR define una lista de códigos de error que, a efectos de seguimiento de trabajos, son tratados como códigos de terminación normales. Esta sentencia la usa un controlador o un controlador en reposo. Puede especificarse más de una vez. La sentencia NOERROR realiza la misma función que la palabra clave NOERROR en la sentencia JTOPTS. Puede usar sentencias NOERROR con la palabra clave NOERROR o en lugar de ella. Cuando crea sentencias NOERROR, puede especificar un número de códigos de error mayor del posible sólo con la palabra clave NOERROR de la sentencia JTOPTS. También puede encontrar útil agrupar códigos de error en sentencias NOERROR distintas. NOERROR se define en el miembro de la biblioteca EQQPARM tal y como se especifica con el parámetro PARM de la sentencia JCL EXEC. Para volver a crear dinámicamente la tabla NOERROR, basándose en sentencias NOERROR actualizadas en el miembro del parámetro principal (es decir, el valor PARM para EXEC PGM=EQQMAJOR), puede ejecutar cualquiera de los siguiente mandatos: F ssnm, NEWNOERR o F ssnm, NOERRMEM(miembro) Por ejemplo, para eliminar todos los cógidos NOERROR definidos por el miembro M1, cambie M1 para que contenga sólo comentarios e introduzca el mandato: F ssnm, NOERRMEM(M1) Notas: 1. Si ha usado alguno de los mandatos anteriores para actualizar dinámicamente la tabla NOERROR y necesita reiniciar el controlador con CURRPLAN(NEW) en la sentencia de inicialización JTOPTS, actualice también las definiciones NOERROR en la biblioteca EQQPARM antes de detener y reiniciar el controlador. Si no lo hace, el planificador no mantendrá los datos actualizados al reiniciar. 2. Si usa el mandato: F ssnm, NOERRMEM(miembro) el planificador sustituye cualquier entrada para el mismo miembro de la tabla NOERROR actual siempre que la entrada sea correcta y consistente con las anteriores. 3. Si desea eliminar una entrada de la tabla NOERROR actual, siga os siguiente pasos: a. Elimine o convierta en comentario esa entrada en el mismo miembro usado para definirla, por ejemplo el miembro M1. b. Use el mandato F ssnm, NOERRMEM(M1) Capítulo 1. Definición de sentencias de inicialización 115 NOERROR Formato , NOERROR LIST( entrada de código de error ) Parámetros LIST(entrada de código de error, ...,entrada de código de error) Especifica una lista de códigos de error que, a efectos de seguimiento de trabajos, son tratados como códigos de terminación normales. Las entradas de la lista tienen dos formatos: un formato general aplicable a todos los trabajos y tareas iniciadas y un formato específico aplicable a un solo trabajo o tarea iniciada, o a un conjunto de trabajos o tareas iniciadas. Una entrada general puede ser: v Un código de retorno de trabajo o de tarea iniciada 4 dígitos (nnnn) v Un código de terminación anómala de sistema (Sxxx) v Un código de terminación anómala de usuario (Uxxx) v Un código definido por IBM Tivoli Workload Scheduler for z/OS Una entrada específica tiene este formato: nombretrabajo.nombrepaso.nombrepasoproc.códigoerror nombretrabajo El nombre de un trabajo o tarea iniciada tal y como se especifica en el campo nombre del trabajo de la operación. La longitud máxima es de 8 caracteres. nombrepaso El nombre del paso que invoca un procedimiento incorporado o catalogado. Es siempre el nombre de una sentencia EXEC PROC. La longitud máxima es de 8 caracteres. Este valor no significa nada para una estación de trabajo Tivoli Workload Scheduler for z/OS agent. nombrepasoproc El nombre de un paso que invoca un programa. Es siempre el nombre de una sentencia EXEC PGM. La longitud máxima es de 8 caracteres. Este valor no significa nada para una estación de trabajo Tivoli Workload Scheduler for z/OS agent. 116 códigoerror El código de error que no debe considerarse como error. La longitud máxima es de 4 caracteres.Para los códigos de error negativos, especifique una secuencia de cinco caracteres que comiencen con el símbolo de resta (-), por ejemplo -0008. operador El nombre del operador relacional que debe usarse junto con el código de error especificado. Este campo es opcional y puede tener hasta dos caracteres de longitud. Los valores válidos son: EQ Igual a (es el valor predeterminado). GE Mayor que o igual a. GT Mayor que. LE Menor que o igual a. LT Menor que. NE No igual a. IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste NOERROR TO Indica un intervalo entre dos valores. Úselo especificando una expresión con forma códigoerror.TO.errorcode2 donde los valores extremos están incluidos. El valor predeterminado es EQ para la compatibilidad con versiones anteriores. códigoerror2 El código de error que no debe considerarse como error, como segundo límite en un intervalo expresado por el operador TO. El código de error corresponde al primer elemento del límite. Puede tener hasta cuatro caracteres de longitud. Es necesario cuando el operador es TO. No lo use cuando especifique otro operador. Cuando se incluye una entrada en el formato especificado, son necesarios los primeros cuatro nombres. Es decir, debe haber al menos tres puntos. Puede usar un asterisco (*) y un signo de porcentaje (%) como parte de los nombres para crear un nombre genérico que pueda coincidir con muchos valores. | | | | | | | | | | | | | | | | Un asterisco puede representar una serie de caracteres de longitud desconocida. Un solo asterisco coincide con cualquier nombre, incluyendo un nombre en blanco. Dos asteriscos adyacentes coinciden con los mismos valores que con un solo asterisco. Más de dos asteriscos adyacentes coinciden con un rango de códigos de error específico, pero para ello se le recomienda utilizar el operador TO. Por ejemplo, para hacer coincidir los códigos de error de 0 a 999, de 1000 a 1999, de 2000 a 2999, y de 3000 a 3999, debe especificar uno de los valores siguientes: | | La segunda sentencia, utilizando el operador TO, es preferible y no requiere el procesamiento de varios asteriscos redundantes. NOERROR LIST(********.********.********.0*** ********.********.********.1*** ********.********.********.2*** ********.********.********.3*** , , , ) O NOERROR LIST(*.*.*0.TO.3999) Use un signo de porcentaje para representar un solo carácter. Un solo signo de porcentaje coincide con cualquier carácter en una posición específica excepto en blanco. El proceso de análisis del planificador realiza las siguientes comprobaciones lógicas: v Entradas duplicadas, por ejemplo (*.*.*.10.EQ, *.*.*.10.EQ) v Entradas solapadas y consistentes, por ejemplo (*.*.*.10.TO.50, *.*.*.15.EQ) v Entradas inconsistentes, por ejemplo: – (*.*.*.100.EQ, *.*.*.100.NE) – (J*.S*.P%S*.120.GE,*.*.*.115.GT) – (*.*.*.0C4.GE ,*.*.*.0C6.GT) Capítulo 1. Definición de sentencias de inicialización 117 NOERROR Como regla general, al procesar sucesos de error, el planificador comprueba la tabla NOERROR de modo secuencial. Tan pronto como el proceso encuentra una condición coincidente NOERROR, deja de explorar la tabla NOERROR. Por lo tanto, debe evitar especificar condiciones ambiguas como comparaciones GE o GT de los ejemplos anteriores: decida qué valor debe usarse para la comparación y defina una sola sentencia. Los resultados de la comprobación son devueltos en mensajes específicos escritos en el registro de mensajes del controlador. Notas: 1. Los códigos de error OSUF, OSUP, OJCV yd OSEQ definidos por Tivoli Workload Scheduler for z/OS son siempre tratados como errores. 2. Para usar la palabra clave NOERROR para un trabajo específico o para pasos de tareas iniciadas, las opciones del grabador de sucesos, tal y como se especifica en la sentencia de inicialización EWTROPTS, deben establecerse del siguiente modo: v La palabra clave STEPEVENTS debe especificar ALL o NZERO. v La palabra clave RETCODE debe especificar HIGHEST. 3. Con PQ87904 APAR, los códigos de error generados por el paso EQQCLEAN, que es un paso insertado en un trabajo reiniciado por la función de reinicio y limpieza, no pueden ser suprimidos por la lógica NOERROR. 4. Cuando establezca el nombre códigoerror con un código definido por IBM Tivoli Workload Scheduler for z/OS (por ejemplo JCLI), establezca el nombre operador como EQ. 5. Los únicos códigos de error aceptables son los que aparecen en el Apéndice E de Managing the Workload. Ejemplos NOERROR NOERROR NOERROR NOERROR NOERROR NOERROR NOERROR LIST(JOBSUBEX.*.*.S806) 1 LIST(CAN) 2 LIST(*.*.*.U001) LIST(TWSJOB2.*.*.0032.LE) LIST(TWSJOB 1.*.*.S806.TO.S810) LIST(*.*.*.10.TO.11,*.*.*.13.TO.15) LIST(*.*.*.0C6.GT) 3 4 5 6 7 En este ejemplo de sentencias NOERROR: 118 1 Cualquier trabajo llamado JOBSUBEX que termine de forma anómala con código de terminación anómala de sistema S806 es tratado como si hubiera terminado normalmente. 2 Cualquier trabajo cancelado por el operador o por un usuario TSO antes de tratar la ejecución es tratado como si hubiera terminado normalmente. 3 Cualquier trabajo que termine de forma anómala con código de terminación anómala U001, es tratado como si hubiera terminado normalmente. 4 Cualquier trabajo llamado TWSJOB2 que termine con código de error inferior o igual a 0032 es tratado como si hubiera terminado normalmente. IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste NOERROR 5 Cualquier error llamado TWSJOB1 que termine de forma anómala con un código de sistema entre S806 (incluido) y S810 (incluido) es tratado como si hubiera terminado normalmente. 6 Cualquier trabajo que termine con un código de error entre 10 (incluido) y 15 (incluido), excepto 12, es tratado como si hubiera terminado normalmente. Nota: No puede gestionar dicho caso combinando las siguientes condiciones: *.*.*.12.NE y *.*.*.10.TO.15 . Por ejemplo, si la tabla NOERROR ya contiene *.*.*.12.NE y añade *.*.*.10.TO.15 , el planificador emite un mensaje de aviso y no añade la segunda entrada. 7 Cualquier trabajo que termine con un código de terminación anómala superior a 0C6 es tratado como si hubiera terminado normalmente. Capítulo 1. Definición de sentencias de inicialización 119 OPCOPTS OPCOPTS Propósito La sentencia OPCOPTS define las opciones de tiempo de ejecución de Tivoli Workload Scheduler for z/OS. Esta sentencia es usada por un comprobador de seguimiento, controlador o un controlador en reposo. OPCOPTS se define en el miembro de la biblioteca EQQPARM tal y como se especifica con el parámetro PARM de la sentencia JCL EXEC. Formato OPCOPTS NO YES APPCTASK( ) NO YES ARM( ) ARPARM( STDAR nombre de miembro ) AUTOMATIONMSG( MLOG SYSLOG BOTH NONE BUILDSSX( MERGE REBUILD ) ) IBM-037 página de códigos del sistema principal CODEPAGE( ) CONTROLLERTOKEN( este subsistema nombre de subsistema ) CPBPLIM( 40 Tamaño de la agrupación de almacenamiento intermedio del programa de control CPDTLIM( 50 Porcentaje de tamaño de conjunto de datos CP ) DB2SYSTEM( subsistema DB2 ) ) STDERDR , 1 número de lectores de sucesos ERDRTASK( ERDRPARM( nombre de miembro EXIT01SZ( 0 número de líneas de JCL EWTRPARM( STDEWTR nombre de miembro ) ) ) NO YES EXTMON( ) ) NO YES EWTRTASK( ) GDGNONST( YES NO ) GMTOFFSET( 0 valor de desplazamiento ) GSTASK( 5 número de solicitudes paralelas ) GTABLE( GLOBAL identificador de tabla ) JCCPARM( STDJCC nombre de miembro ) JCCTASK( NO YES ) JESPLEX( , Nombre del sistema NCFAPPL( Nombre de unidad lógica VTAM ) MAXHISTORYROWS( 5000 número de filas ) ) NCFTASK( NO YES ) NOERRCONCHECK( ) OPCHOST( 120 YES NO MSG YES NO STANDBY PLEX ) OPERHISTORY( NO YES IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste ) RCLEANUP ( NO YES ) OPCOPTS RCLPASS ( NO YES ) NO YES RECOVERY( ) NO YES REMJCLDIRECTIVES( ) RODMPARM( STDRODM nombre de miembro ) RODMTASK( NO YES SAVARFAIL( &, % ) ) SECHECK( NO ALL OPERONLY , ) SPIN( SERVERS( Nombre de tarea iniciada NO YES ) ) SSCMNAME( nombre de módulo TEMPORARY PERMANENT , ) SUPPRESSENF( NO YES ) SYSPLEXID( 1 identificador de Sysplex ) TASKUSR( YES NO ) TPLGYSRV( nombre de servidor ) VARSUB( SCAN YES NO VARFAIL( & % ? ) ) VARPROC( NO YES ) WLM( WLMJOBPR nombre de clase CONDITIONAL( 20 por ciento , nombre de política ) ) DURATION DEADLINE LATESTSTARTTIME Parámetros APPCTASK(YES|NO) Especifique YES si se usa un comprobador de seguimiento AS400 o hay programas usando la interfaz API. 'appctask' no es necesaria para la comunicación con el servidor de Tivoli Workload Scheduler for z/OS. Puede especificar APPCTASK para un comprobador de seguimiento y un controlador. ARPARM(nombre de miembro|STDAR) Define el nombre del miembro del conjunto de datos de EQQPARM que contiene una sentencia AROPTS para la tarea de recuperación automática de trabajos. ARM(YES|NO) El gestor de reinicio automático (ARM) de z/OS puede reducir el impacto de un código de error inesperado en Tivoli Workload Scheduler for z/OS porque z/OS puede reiniciarlo automáticamente sin que intervenga el operador. Especifique YES si debe activarse el reinicio automático del componente anómalo de Tivoli Workload Scheduler for z/OS y defina el componente en la biblioteca del ARM. El nombre del elemento contiene la serie "OPC", el SYSTEMID y el nombre SUBSYSTEM. La recuperación ARM del componente anómalo de Tivoli Workload Scheduler for z/OS es posible en la misma imagen (reinicio). Esta característica permite la recuperación del comprobador de seguimiento y un reinicio rápido del controlador y el servidor. Además, el reinicio no reduce el número de controladores en reposo cuando hay una anomalía en el controlador. Puede personalizar el número de reinicios y el período de un reinicio estableciendo los parámetros para cada componente de Tivoli Workload Scheduler for z/OS en la política ARM de z/OS. Capítulo 1. Definición de sentencias de inicialización 121 OPCOPTS AUTOMATIONMSG(MLOG|SYSLOG|BOTH|NONE) Define dónde deben registrarse los mensajes emitidos por System Automation. Puede especificar uno de los siguientes: MLOG Registro de mensajes de Tivoli Workload Scheduler for z/OS, es el valor predeterminado. SYSLOG Registro del sistema. BOTH Registro de mensajes de Tivoli Workload Scheduler for z/OS y registro del sistema. NONE No se registran ninguno de los mensajes emitidos por System Automation. Recuerde que el mensaje EQQE123I se registra en MLOG independientemente del valor establecido para esta palabra clave. Esta opción sólo es válida si ejecuta System Automation versión 3.1 (con el nivel de mantenimiento correcto instalado), o posterior. BUILDSSX(MERGE|REBUILD) Define si la extensión de la tabla de vectores de comunicación (CVT) del subsistema para Tivoli Workload Scheduler for z/OS, la SSX, debe volver a crearse a un nuevo nivel cuando se inicia el espacio de direcciones. La SSX es creada con la inicialización del subsistema por el módulo EQQINITJ. Si el módulo EQQINITJ se ha actualizado desde entonces, por mantenimiento o porque se está instalando una nuevo nivel de liberación o modificación de Tivoli Workload Scheduler for z/OS, use la palabra clave BUILDSSX para evitar una IPL de z/OS. Especifique MERGE cuando deban copiarse datos operacionales, por ejemplo la cola del grabador de sucesos, a la nueva SSX. Esto garantiza que la nueva cola de grabador de sucesos es preparada con sucesos en la cola del bloque SSX anterior. Use esta opción cuando inicie un espacio de direcciones de Tivoli Workload Scheduler for z/OS después de instalar actualizaciones de mantenimiento. Especifique REBUILD cuando migre a, o realice un repliegue de, un nuevo nivel de liberación o modificación de Tivoli Workload Scheduler for z/OS. En la nueva SSX no se hará referencia a la cola de grabador de sucesos de la SSX anterior. Asegúrese también de identificar el nombre de módulo de comunicación nuevo usando la palabra clave SSCMNAME. Notas: 1. La sección ++HOLD de la carta de presentación del PTF identifica las actualizaciones de servicio que exigen que se vuelva a crear la SSX. 2. MERGE no puede ser usada cuando se crean los bloques de SSX anteriores y nuevos para FMID distintos. No use MERGE cuando migre a, o realice un repliegue de, un nuevo nivel de liberación o modificación de Tivoli Workload Scheduler for z/OS. 3. Si especifica BUILDSSX(REBUILD) para migrar a, o realizar un repliegue de, un nivel nuevo de liberación o modificación de Tivoli Workload Scheduler for z/OS, asegúrese también de especificar la palabra clave SSCMNAME. 4. El parámetro BUILDSSX debe eliminarse después de la siguiente IPL del sistema z/OS porque ya no es necesaria. 122 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste OPCOPTS CODEPAGE (página de códigos del sistema principal|IBM–037) El nombre de la página de código de host. Este valor es usado por la tarea de supervisión para convertir los datos de supervisión que deben ser enviados al agente de supervisión. Puede proporcionar el valor IBM–nnn, donde nnn es la página de códigos EBCDIC. El valor predeterminado, IBM–037, define la página de códigos EBCDIC para inglés americano, portugués y francés de Canadá. A continuación se muestra una lista de las páginas de códigos EBCDIC: IBM–939 Japón, extendido IBM–937 Taiwán IBM–935 China IBM–933 Corea IBM–975 Grecia IBM–971 Islandia IBM–970 Latín 2 IBM–838 Tai IBM–500 Internacional IBM–424 Israel IBM–297 Francia IBM–285 Reino Unido IBM–284 España - América latina IBM–280 Italia IBM–278 Suecia - Finlandia IBM–277 Dinamarca - Noruega IBM–274 Bélgica IBM–273 Alemania IBM–1388 China IBM–1122 Estonia IBM–1112 Báltico IBM–1047 Sistemas abiertos IBM–1026 Latín 5 (Turquía) IBM–1025 Cirílico A continuación se muestra una lista de las páginas de códigos EBCDIC que aceptan EURO: IBM–1140 Finlandia, Suecia IBM–1141 Austria, Alemania IBM–1142 Dinamarca, Noruega IBM–1143 EE.UU. IBM–1144 Italia IBM–1145 España , América latina IBM–1146 Reino Unido IBM–1147 Francia IBM–1148 Bélgica, Suiza IBM–1149 Islandia CONTROLLERTOKEN(nombre de subsistema|este subsistema) Esta palabra clave se usa para la función de historial. El nombre de subsistema es una clave para la información de historial. Cuando el plan actual es ampliado, se usa el valor BATCHOPT CONTROLLERTOKEN para grabar la información. Cuando se recupera la información de la base de datos, se usa el valor OPCOPTS CONTROLLERTOKEN, así se pueden volver a ejecutar trabajos iniciados desde el plan actual de otro subsistema (por ejemplo, cuando un sistema en reposo sustituye al principal) especificando la señal correcta después de la sustitución. Capítulo 1. Definición de sentencias de inicialización 123 OPCOPTS Si especifica OPERHISTORY(NO) u omite la palabra clave OPERHISTORY, se ignora la palabra clave CONTROLLERTOKEN. CPBPLIM (Tamaño de la agrupación de almacenamiento intermedio del programa de control |40) El tamaño de la agrupación de almacenamiento intermedio del programa de control se establece como la mitad de tamaño del plan actual, pero está limitado a un porcentaje determinado de la cantidad de almacenamiento disponible; este porcentaje viene dado por la palabra clave CPBPLIM. Los valores permitidos son 0-99. Los valores entre el 1 y el 99 son considerados como un porcentaje; el valor 0 provoca la restricción anterior, 400 bloques. El valor predeterminado es un porcentaje de 40. CPDTLIM (porcentaje de tamaño de conjunto de datos CP|50) Esta palabra clave determina el porcentaje del tamaño del plan actual utilizado como máximo para el tamaño de la agrupación de almacenamiento intermedio. Si se omite CPDTLIM se utiliza el valor predeterminado 50. Los valores permitidos son 0-100. Los valores 1-100 se consideran como porcentaje; el valor 0 hace que se utilice el valor predeterminado de 50. Los valores recomendados se encuentran entre 50 y 100. DB2SYSTEM(subsistema DB2) Esta palabra clave es necesaria para la función de historial. Especifica el subsistema DB2, igual que en el miembro IEFSSNxx de SYS1.PARMLIB. Si especifica OPERHISTORY(YES) pero omite la palabra clave DB2SYSTEM, se emite un mensaje de error. ERDRPARM(nombre de miembro|STDERDR) Define los nombres de los miembros del conjunto de datos EQQPARM que contienen una sentencia ERDROPTS para una tarea de grabador de sucesos. El número de nombres de miembros de esta lista debe ser igual al número de tareas de lector de sucesos tal y como lo define la palabra clave ERDRTASK. Esta palabra clave es necesaria si se inicia más de un suceso. ERDRTASK(número de lectores de sucesos|1) Define el número de tareas de lector de sucesos que deben ser activados por el Tivoli Workload Scheduler for z/OS. El número máximo es 16. Notas: 1. Si no deben iniciarse tareas de lector de sucesos, debe especificarse ERDRTASK(0). 2. Por lo que respecta al controlador, deben iniciarse tareas de lector de sucesos independientes cuando hay comprobadores de seguimiento conectados mediante DASD compartidos. 3. Por lo que respecta al comprobador de seguimiento, es aconsejable (por razones de rendimiento) no iniciar una tarea de lector de sucesos independiente estableciendo ERDRTASK(0). La función de lector de sucesos debe activarse en una tarea de grabador de sucesos especificando EWSEQNO en la sentencia EWTROPTS. EWTRPARM(nombre de miembro|STDEWTR) Define el nombre del miembro del conjunto de datos de EQQPARM que contiene una sentencia EWTROPTS para la tarea de grabador de sucesos. EWTRTASK(YES|NO) Especifique YES si el subsistema de Tivoli Workload Scheduler for z/OS debe iniciar una tarea de grabador de sucesos para crear sucesos en un conjunto de datos de sucesos. 124 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste OPCOPTS | | | | | | | | | | | GDGNONST(YES|NO) Si ha establecido esta palabra clave en No, Tivoli Workload Scheduler for z/OS prueba la sección JCFGDG para reconocer si un conjunto de datos es miembro de GDG. Esto significa que la función desencadenante del conjunto de datos no reconoce como GDG el conjunto de datos al que se hace referencia en el código JCL en formato ampliado. Nota: Es posible que la función reinicio y limpieza no funcione correctamente con GDG. Si establece esta palabra clave en Yes, Tivoli Workload Scheduler for z/OS asume que un conjunto de datos que tiene su última sintaxis de calificador compatible con un miembro de GDG, es un miembro de GDG. EXIT01SZ(número de líneas de JCL|0) Esta palabra clave, si se especifica con un valor distinto de cero, le dice a Tivoli Workload Scheduler for z/OS que el tamaño del JCL puede cambiarse mediante la salida de usuario 01, y que el nuevo tamaño del JCL no puede ser superior al valor especificado. Por ejemplo, un valor de 5000 establecerá el límite a 5000 líneas de JCL. Se considera de cada línea de JCL tiene 80 caracteres de longitud. EXTMON (YES|NO) Especifique YES para permitir que Tivoli Workload Scheduler for z/OS se comunique con Tivoli Business System Manager. Tivoli Business System Manager es notificado de cualquier alerta o cambio de estado relacionado con los trabajos supervisados. Especifique NO si no desea supervisión. GMTOFFSET(valor de desplazamiento|0) Esta palabra clave se usa para solicitar que Tivoli Workload Scheduler for z/OS corrija el reloj GMT reconocido como incorrecto. El valor del parámetro de la palabra clave define cuánto debe corregirse el reloj. El valor debe ser un número, positivo o negativo, inferior a 1440 (24 horas) que defina el número de minutos que deben añadirse al valor del reloj GMT en este sistema (donde se usa la palabra clave), para obtener la hora GMT real. El valor predeterminado es cero (GMTOFFSET(0), es decir, el reloj GMT muestra la hora GMT real. Nota: Este parámetro sólo permite que Tivoli Workload Scheduler for z/OS ignore el proceso de sincronización GMT y no permite la interpretación correcta de la indicación de fecha en sucesos recibidos desde el comprobador de seguimiento cuando se establece la conexión. Por lo tanto, la hora de inicio y de terminación reales de las operaciones relacionadas serán desviadas por la cantidad de desplazamiento especificada. GSTASK(número de registros paralelos|5) Define el número de solicitudes de diálogo que pueden ser manejadas simultáneamente por la subtarea de servicios generales hasta un máximo de 5. Por lo tanto, GSTASK(1) no permitirá el proceso paralelo de solicitudes, pero GSTASK(5), el valor predeterminado, permitirá el proceso paralelo máximo. GTABLE(identificador de tabla|GLOBAL) Define el nombre de la tabla de variables globales del JCL para el complejo de Tivoli Workload Scheduler for z/OS. Esta tabla contiene definiciones de variables de JCL que pueden usarse para cualquier operación dentro del complejo de Tivoli Workload Scheduler for z/OS. Se busca la tabla de variables Capítulo 1. Definición de sentencias de inicialización 125 OPCOPTS globales cuando no puede encontrarse una tabla (o variable dentro de una tabla) a la que hace referencia una operación. Si planifica la característica global con capacidades de tolerancia a errores, establezca esta palabra clave con el mismo valor que el de la palabra clave GTABLE en la sentencia BATCHOPT Puede especificar sólo un identificador de tabla para el complejo de Tivoli Workload Scheduler for z/OS. Tivoli Workload Scheduler for z/OS usa el nombre predeterminado GLOBAL si no se especifica un identificador de tabla. JCCPARM(nombre de miembro|STDJCC) Define el nombre del miembro del conjunto de datos de EQQPARM que contiene una sentencia JCCOPTS para la tarea de comprobación de terminación de trabajo. JCCTASK(YES|NO|) Especifique JCCTASK (YES) si debe usarse la función de comprobación de terminación de trabajo. Especifique JCCTASK (NO) si no debe usarse la función de comprobación de terminación de trabajo. JESPLEX(lista de nombres de sistema) Ofrece una lista de los nombres de sistemas dentro de JESplex al que pertenece el comprobador de seguimiento. Los nombres de sistemas pueden tener hasta 8 caracteres. MAXHISTORYROWS(número de filas|5000 Esta palabra clave, si se especifica con un valor distinto de cero, le indica a Tivoli Workload Scheduler for z/OS el número máximo de filas que se pueden recuperar de DB2 utilizando el mandato HIST. El valor predeterminado es 5000. El valor máximo es 999999. Si indica 0, todas las filas se recuperan sin limitaciones. Por ejemplo, indicando 1000 se establece 1000 como número máximo de filas que puede recuperar el procesamiento del mandato HIST. Si se recuperan menos de 1000 filas, éstas se muestran en el panel solicitante. Si se recuperan más de 1000 filas, se interrumpe el procesamiento del mandato HIST, se emite un mensaje de error y no se muestran datos en el panel solicitante. Para reducir la cantidad de datos que recuperar, establezca los criterios de filtrado adecuados. NCFAPPL(Nombre de unidad lógica de VTAM) Especifique el nombre de unidad lógica de VTAM asociado al subsistema. Esta palabra clave es necesaria si se especifica NCSK(YES). NCFTASK(YES|NO) Especifique YES si el subsistema debe iniciar una tarea de función de comunicación de red (NCF). Es decir, la comunicación se realiza mediante VTAM. NOERRCONCHECK(YES|NO|MSG) Define qué nivel de comprobación realiza el planificador al añadir entradas a la tabla NOERROR. Puede especificar uno de los siguientes: 126 YES Hay activa una comprobación de consistencia. El planificador no añade entradas inconsistentes a la tabla NOERROR y emite mensajes EQQN069W en el registro de mensajes del controlador para indicar las inconsistencias. Es el valor predeterminado. NO Para forzar al planificador a actualizar la tabla NOERROR incluso IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste OPCOPTS después de detectar entradas inconsistentes. No se emiten mensajes EQQN069W relacionados. El mensaje EQQN098I (que informa de que la tabla ha sido actualizada basándose en el valor NOERRCONCHECK) no se ha emitido tampoco. Establecer esta palabra clave en NO evita que se realice cualquier comprobación de coherencia. MSG Al igual que el valor NO, fuerza al planificador a actualizar la tabla NOERROR incluso después de detectar entradas inconsistentes. Al contrario que el valor NO, se emiten mensajes EQQN069W relacionados. Se emite el mensaje EQQN098I informando de que la tabla ha sido actualizada basándose en el valor NOERRCONCHECK. OPCHOST(NO|STANDBY|YES|PLEX) Especifique YES si este subsistema da soporte a usuarios de diálogos y contiene las bases de datos y los planos. Especifique NO si este subsistema no es el sistema controlador. Especifique STANDBY si este subsistema debe estar preparado para cambiar de ser ejecutado en modalidad de host o no. OPCHOST(STANDBY) sólo es válida en un entorno XCF. No puede especificar OPCHOST(STANDBY) y EWTRTASK(YES) en la misma sentencia OPCOPTS. Especifique PLEX si este subsistema debe iniciarse como sistema controlador. Si ya hay un controlador activo en el grupo XCF, el inicio continúa como controlador en reposo. OPCHOST(PLEX) sólo es válida cuando se han especificado XCF GROUP y MEMBER. Además, esta selección requiere que IBM Tivoli Workload Scheduler for z/OS se esté ejecutando en un sistema z/OS/ESA Version 4 Release 1 o posterior. Si se inicia IBM Tivoli Workload Scheduler for z/OS con OPCHOST(YES), NMM inicializa el conjunto de datos de CKPT con FMID y nivel correspondiente a SSX. OPERHISTORY(YES|NO) Esta palabra clave es necesaria para la función de historial. Especifica que Tivoli Workload Scheduler for z/OS almacenará información de las operaciones terminadas en la base de datos DB2. Si especifica YES, también debe especificar la palabra clave DB2SYSTEM. Si especifica YES pero omite la palabra clave DB2SYSTEM, se emite un mensaje de error. Si especifica NO u omite la palabra clave OPERHISTORY, pero especifica palabras clave relacionadas (por ejemplo DB2SYSTEM o CONTROLLERTOKEN) se emite un mensaje de aviso para informarle de que la función de historial no está activa. RCLEANUP (YES/NO) El valor predeterminado es NO. Especifique YES para usar la función de reinicio y limpieza: El valor de RCLEANUP debe coincidir con el valor de BATCHOPT para RCLEANUP. Si se codifica RCLEANUP(YES), los registros CP16 creados por el trabajo por lotes (si BATCHOPT tiene especificado RCLEANUP(YES)) son eliminados como parte del proceso de actualización. Se inician las tareas FL y PSU, se activa el almacén de datos local y el planificador cambia los trabajos para duplicar la salida a OPC DEST ID. Cuando se especifica YES, OUTPUTNODE(FINAL) es forzada en la sentencia JTOPTS. RCLPASS (YES|NO) El valor predeterminado es NO. Especifique YES para usar la función de reinicio y limpieza para JCL con DISP=(,PASS) en el último paso. Capítulo 1. Definición de sentencias de inicialización 127 OPCOPTS RECOVERY(YES|NO) Especifique YES si el controlador debe iniciar una tarea de recuperación automática de trabajos para gestionar automáticamente operaciones terminadas en error. Nota: Si especifica RECOVERY(NO), no puede usar el diálogo Funciones de servicio para activar la tarea de recuperación automática de trabajos. REMJCLDIRECTIVES(YES|NO) Define si deben eliminarse las directivas JCL del JCL a la hora de envío. Espcifique YES para eliminar las directivas del JCL a la hora de envío. En este caso, el planificador elimina las directivas antes de enviar el JCL, por lo tanto la salida de trabajo no contiene las directivas. Especifique NO para mantener las directivas en el JCL a la hora de envío. En este caso la salida de trabajo contiene las directivas. RODMPARM(nombre de miembro|STDRODM) Especifica el miembro del conjunto de datos EQQPARM que contiene sentencias RODMOPTS para la subtarea RODM (resource object data manager). RODMPARM no es usada por un comprobador de seguimiento. RODMTASK(YES|NO) El soporte que IBM Tivoli Workload Scheduler for z/OS da a RODM (resource object data manager) permite asociar campos de recursos especiales en el plan actual con campos de clases RODM u objetos RODM. El soporte para RODM requiere que: v Se inicia un comprobador de seguimiento en la misma imagen de z/OS que la del subsistema RODM al que se envían las solicitudes y se especifica RODMTASK(YES) para el comprobador de seguimiento y el controlador. v Se inicia un grabador de sucesos en el espacio de direcciones de Tivoli Workload Scheduler for z/OS que se comunica con RODM. Este espacio de direcciones crea sucesos de recursos (tipo S) desde notificaciones RODM que Tivoli Workload Scheduler for z/OS usa para actualizar el plan actual. v El controlador se conecta al comprobador de seguimiento mediante XCF, NCF, TCP/IPo un conjunto de datos de envío/liberación. v Cada espacio de direcciones tiene un identificador de usuario RACF único si se comunica más de 1 espacio de direcciones de Tivoli Workload Scheduler for z/OS con un subsistema RODM, por ejemplo cuando se inician sistemas de producción y de prueba suscritos al mismo subsistema RODM. Tivoli Workload Scheduler for z/OS puede comunicarse con varios subsistemas RODM. SAVARFAIL(&, %) Esta palabra clave le dice a Tivoli Workload Scheduler for z/OS que no considere las variables sin resolver del mandato de System Automation como un error, impidiendo que la operación termine con código de error OJCV. Los tipos de variables permitidas son el carácter & y el signo de porcentaje (%). Puede usar uno de estos signos o los dos, en cualquier orden, para ignorar la anomalía de sustitución. Por ejemplo, si establece SAVARFAIL(&), Tivoli Workload Scheduler for z/OS no considera como error la sustitución anómala de variables que comienzan por &. Se permite cualquier combinación de los dos tipos de variables, por ejemplo SAVARFAIL(&, %) o SAVARFAIL(%, &), pero debe especificar al menos un tipo. Si no se establece SAVARFAIL, la sustitución anómala de una variable se considera como un error de oeración. 128 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste OPCOPTS SECHECK(ALL|OPERONLY|NO) Esta palabra claves aplica a comprobadores de seguimiento y controladores en los que está activa la función Enviar (se usa un destino en blanco para enviar trabajos localmente). Para activar entornos de planificación WLM, debe especificar un valor distinto de NO. Cuando active esta función, debe hacerlo para todos los comprobadores de seguimiento y para el controlador que hay dentro del mismo sysplex. Esto es necesario para implementar correctamente el mecanismo de escucha ENF, porque los comprobadores de seguimiento activan las salidas de escucha sólo en el sistema MVS donde está ubicado. Los valores posibles son los siguientes: ALL Deben comprobarse todos los JCL enviados en busca de un nombre de entorno de planificación asociado. La comprobación es la siguiente: 1. Si se define, se usa el nombre de entorno de planificación asociado a la operación. En este caso, el JCL se adapta añadiendo o sustituyendo la palabra clave SCHENV de la sentencia de la tarjeta JOB. Se sobrescribe cualquier valor existente previamente en el JCL. 2. Si la condición anterior no es true, se usa el nombre de entorno de planificación especificado en la palabra clave SCHENV de la sentencia de la tarjeta JOB si está presente. 3. Si la condición anterior no es true, no se usa ningún nombre de entorno de planificación (no se consulta WLM). Cuando se encuentra un entorno de planificación, se consulta WLM para comprobar si está disponible el entorno. Si lo está, se somete el trabajo, de lo contrario: v Si no está disponible el entorno, se establece la operación como READY, WAITING FOR SE v Si no está definido el entorno, se establece la operación como terminada en error (código de error SEUN) OPERONLY Sólo deben comprobarse los JCL de operaciones con un entorno de planificación definido en la base de datos de Tivoli Workload Scheduler for z/OS. La comprobación es la siguiente: v Se usa el nombre de entorno de planificación asociado a la operación para insertar o actualizar en el JCL la palabra clave SCHENV de la sentencia de la tarjeta JOB. Cuando esto sucede, se sobrescribe el valor existente en el JCL. v Se consulta WLM para ver si está disponible el entorno. Si lo está, se somete el trabajo, de lo contrario: – Si no está disponible el entorno, se establece la operación como READY, WAITING FOR SE – Si no está definido el entorno, se establece la operación como terminada en error (código de error SEUN) NO No se realizan comprobaciones. Éste es el valor predeterminado. Nota: Cuando se adapta la tarjeta JOB para insertar o sustituir la palabra clave del valor SCHENV=new, es posible que se ignore cualquier comentario a la derecha y podría aparecer truncado en el JCL enviado. Capítulo 1. Definición de sentencias de inicialización 129 OPCOPTS SERVERS(Nombre de tarea iniciada, Nombre de tarea iniciada...) Identifica uno o más servidores que deben ser iniciados y detenidos por este controlador. Use este parámetro en un entorno sysplex para permitir que un controlador en reposo se hace cargo de la comunicación. SPIN(YES|NO) Esta palabra clave habilita o inhabilita el uso de la funcionalidad JESLOG SPIN disponible con z/OS 1.2 o posterior. Si especifica YES, se habilita el uso de la funcionalidad JESLOG SPIN. Debido a que las funciones de reinicio y limpieza o de comprobación de terminación de trabajo no dan soporte a esta funcionalidad, cuando las use se emitirá un mensaje de aviso. Si especifica NO, se inhabilita el uso de la funcionalidad JESLOG SPIN añadiendo JESLOG=NOSPIN a la tarjeta JOB de todos los trabajos enviados. SPIN(NO) es efectiva sólo si se especifica RCLEANUP(YES) o JCCTASK(YES). Si usa la función de reinicio y limpieza, se añade automáticamente una tarjeta JOB a cada JCL enviado cuando falta. Si no usa la función de reinicio y limpieza (RCLEANUP(NO)), se emite un mensaje de aviso para cada JCL enviado que no tenga una tarjeta de trabajo. El valor predeterminado es NO. Nota: Cuando se adapta la tarjeta JOB para insertar o sustituir la palabra clave del valor JESLOG=NOSPIN, es posible que se ignore cualquier comentario a la derecha y podría aparecer truncado en el JCL enviado. SSCMNAME(nombre de módulo,PERMANENT|TEMPORARY) El primer valor de la palabra clave define el nombre del módulo de comunicación de subsistema que debe usarse en lugar de EQQSSCMJ que fue cargada en IPL. El segundo valor de la palabra clave especifica si el módulo debe sustituir al cargado en IPL. Use esta palabra clave para cargar una versión actualizada del módulo antes de una IPL planificada. El módulo especificado debe residir en una biblioteca autorizada por APF definida por el ddname STEPLIB o la concatenación LNKLSTnn. Si no se especifica SSCMNAME o se especifica un módulo que no puede ubicarse en una biblioteca autorizada, los sucesos de Tivoli Workload Scheduler for z/OS seguirán siendo generados por EQQSSCMJ cargada en IPL. Especifique PERMANENT como segundo valor de palabra clave para sustituir el módulo de comunicación de subsistema cargado en IPL con el módulo identificado en el primero valor de la palabra clave. En este caso el módulo especificado debe residir en una biblioteca autorizada por APF definida por el ddname STEPLIB. Cuando se especifica TEMPORARY o se establece como segundo valor de la palabra clave, el módulo especificado generará sucesos de seguimiento de trabajos de Tivoli Workload Scheduler for z/OS sólo cuando esté activo el espacio de direcciones de Tivoli Workload Scheduler for z/OS. Cuando se detiene el espacio de direcciones, el módulo EQQSSCMJ cargado en IPL sigue generando sucesos. Notas: 1. La sección ++HOLD de la carta de presentación del PTF identifica actualizaciones de servicio que requieren cargar un módulo de comunicación de subsistema nuevo. 2. Asegúrese de especificar esta palabra clave cuando se use la opción BUILDSSX(REBUILD) para migrar a, o realizar un repliegue de, un nuevo nivel de liberación o modificación de Tivoli Workload Scheduler for z/OS. 3. La palabra clave SSCMNAME debe eliminarse después de la siguiente IPL ya que porque ya no es necesaria. 130 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste OPCOPTS SUPPRESSENF(YES|NO) Especifica si deben volver a llamarse a la activación de salidas de escucha de ENF 57 y ENF 41. YES Las salidas ENF 57 y ENF 41 no deben activarse aunque estén marcadas para activación (porque se especificó un valor distinto de NO para SECHECK). NO No debe recuperarse la activación de las salidas. Es el valor predeterminado. No debe establecer este parámetro a YES en comprobadores de seguimiento ubicados en un sysplex que no sea en el que está el controlador. Puede suprimir la activación de las salidas en comprobadores de seguimiento que pertenezcan al mismo sysplex que el controlador sólo si hay un comprobador de seguimiento en la misma imagen MVS que el controlador y si están activas las salidas ENF (SECHECK no está establecido como NO). SYSPLEXID (nnn) Identifica el sysplex donde está ubicado el controlador o el comprobador de seguimiento. nn es un número entero que va de 1 a 9999. El valor predeterminado es 1. | | | TASKUSR(NO|YES) Especifica si una tarea iniciada se va a ejecutar con el ID de usuario asociado a la tarea en lugar del ID de usuario especificado con el nombre de trabajo. | | YES La tarea se ejecuta con el ID de usuario asociado al nombre de la tarea iniciada. Es el valor predeterminado. | NO La tarea se ejecuta con el ID de usuario asociado al nombre del trabajo. TPLGYSRV (nombre_servidor) Activa la característica de planificación global con capacidad de tolerancia a errores en el controlador. Si especifica esta palabra clave se inicia la tarea de habilitador de IBM Tivoli Workload Scheduler. Definir este parámetro requiere la definición de un segmento OMVS para el identificador de usuario del controlador. El nombre_servidor especificado es el del servidor que maneja los sucesos hasta y desde los agentes distribuidos. Sólo puede manejar sucesos hasta y desde los agentes distribuidos un servidor. VARSUB(YES|NO|SCAN) Esta palabra clave le dice a Tivoli Workload Scheduler for z/OS si debe realizar la sustitución de variables de JCL. YES significa que se realiza exploración para las operaciones de todos los sistemas. NO significa que no se produce exploración. SCAN le dice Tivoli Workload Scheduler for z/OS que busque variables de JCL si se encuentra la directiva //*%OPC SCAN en el JCL. Esta palabra clave también es aplicable a la sustitución de variables en el texto del mandato System Automation. YES y SCAN significan que se explora el texto del mandato en busca de sustitución de variables. NO significa que no se realiza exploración de variables. VARFAIL(&, %, ?) Esta palabra clave le dice a Tivoli Workload Scheduler for z/OS si las variables sin resolver del JCL podrían provocar un error JCL (OJCV). Puede usar de uno a tres de los siguiente caracteres, en cualquier orden, para ignorar la anomalía de sustitución (&, %, ?). Capítulo 1. Definición de sentencias de inicialización 131 OPCOPTS Si, por ejemplo, se especifica VARFAIL(&), Tivoli Workload Scheduler for z/OS no considerará como error la anomalía de una sustitución de variables que comiencen con &. Se permite cualquier combinación de los tres tipos, por ejemplo, VARFAIL(&, %) o VARFAIL(?), pero debe especificarse al menos un valor mientras que se rechazará cualquier repetición de caracteres. Si no se especifica VARFAIL, entonces se tratarán como error todas las variables de sustitución, como anteriormente. Recuerde que la opción de ignorar el error no es aplicable a la directiva de Tivoli Workload Scheduler for z/OS y las variables dependientes. VARPROC(YES|NO) Esta palabra clave le dice a Tivoli Workload Scheduler for z/OS si los procedimientos en línea deben considerar la sustitución de variables. Si se especifica VARPROC(YES), se reolverán las variables en procedimientos en línea. El valor predeterminado es NO. WLM(nombre de clase|WLMJOBPR, nombre de política, CONDITIONAL(20)) La palabra clave WLM define las opciones que deben aplicarse para la intervención del gestor de carga de trabajo. La función WLM puede usarse para asignar recursos extra a trabajos críticos que llegan tarde. Tivoli Workload Scheduler for z/OS hace esto promoviendo un trabajo crítico retrasado a una clase de servicio WLM de mayor rendimiento. WLM se define en el miembro de la biblioteca EQQPARM tal y como se especifica con el parámetro PARM de la sentencia JCL EXEC. Nombre de clase El nombre de la clase de servicio WLM al que se promueven trabajos críticos retrasados. Puede ser una clase de servicio existente o una clase de servicio nueva creada para este objetivo. Nombre de política El modo en que Tivoli Workload Scheduler for z/OS decide si un trabajo crítico se está retrasado. Aquí debe especificarse una de las cuatro políticas posibles, y es la política predeterminada que aplicará Tivoli Workload Scheduler for z/OS. Este valor predeterminado puede ser sobrescrito a nivel de trabajo individual. La siguiente es una lista de los nombres de políticas válidos: DURATION Cuando un trabajo crítico excede la duración estimada (tal y como se especifica en el plan actual), Tivoli Workload Scheduler for z/OS lo mueve a la clase de servicio de mayor rendimiento, según también el valor ALEACTION o LIMFDBK establecido en la sentencia JTOPTS. (Para obtener detalles sobre las palabras clave ALEACTION y LIMFDBK, consulte “JTOPTS” en la página 85.) Nota: El hecho de que un trabajo exceda su duración estimada no implica necesariamente que se esté retrasando o que afecte negativamente al plan en general. Especificar esta política podría significar que los recursos extra se utilizan en un trabajo sin ser estrictamente necesario. DEADLINE Cuando se ejecuta un trabajo crítico más allá de su hora límite 132 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste OPCOPTS (calculada como Última hora de inicio + Duración), Tivoli Workload Scheduler for z/OS lo mueve a la clase de servicio de mayor rendimiento. Nota: Si se usa esta política, los recursos extra se utilizan en un trabajo sólo cuando los necesita de verdad. Los recursos extra ayudan a reducir el retraso. LATESTSTARTTIME Cuando se inicia un trabajo crítico más allá de su última hora límite, Tivoli Workload Scheduler for z/OS lo promueve a una clase de servicio de mayor rendimiento. Nota: Usando esta política mejora los resultados, ya que los recursos extra se utilizan en el trabajo durante todo su tiempo de ejecución. Sin embargo, con esta política, es posible compensar en exceso, dedicando recursos extra a un trabajo más tiempo del necesario. Por ejemplo,un trabajo ejecutado durante mucho tiempo puede iniciarse tan solo unos minutos tarde, pero obtener demasiados recursos extra que permitan que termine pronto. CONDITIONAL (NN) Esta política usa una sencilla prueba que decide si se aplica la política de hora límite o de última hora de inicio cuando se inicia un trabajo crítico después de su última hora de inicio. El valor numérico (NN) especificado en esta política define un umbral usado del siguiente modo: Si(Retraso÷Tiempo hasta hora límite)×100 > NN entonces Tivoli Workload Scheduler for z/OS mueve el trabajo inmediatamente a la clase de servicio de mayor rendimiento. Esto aplica de forma eficaz la política de última hora de inicio. Si (Retraso÷Tiempo hasta hora límite)×100 <= NN entonces Tivoli Workload Scheduler for z/OS no realiza ninguna acción hasta que el trabajo se ejecute más allá de su hora límite. Esto es para evitar una compensación excesiva. Nota: SI usa el nombre de miembro predeterminado para ARPARM, ERDRPARM, EWTRPARM, JCCPARM o RODMPARM, debe definir el miembro. Ejemplos OPCOPTS OPCHOST(YES) NCFTASK(YES) NCFAPPL(NCFAPPL1) ERDRTASK(2) ERDRPARM(ERDR1,ERDR2) GMTOFFSET(60) GTABLE(GVARTAB) SERVERS(OPCBCOM1,OPCBCOM2)... 1 2 3 4 5 6 7 8 En este ejemplo de una sentencia OPCOPTS: 1 Tivoli Workload Scheduler for z/OS se inicia como un controlador. Este sistema da soporte a usuarios de diálogos. Capítulo 1. Definición de sentencias de inicialización 133 OPCOPTS 134 2 Se inicia la función de comunicación de red (NCF). 3 El controlador tiene el nombre de unidad lógica VTAM NCFAPPL1. 4 Se inician dos tareas de lector de sucesos. 5 Se especifican las opciones de tiempo de ejecución para las tareas de lector de sucesos en los miembros ERDR1 y ERDR2 de la biblioteca de parámetros. 6 Tivoli Workload Scheduler for z/OS añade una hora a los valores de reloj GMT recuperados desde el sistema que se está ejecutando. 7 Este complejo de Tivoli Workload Scheduler for z/OS usa una tabla de variables de JCL llamada GVARTAB. 8 Se inicia un servidor para manejar la comunicación a un controlador determinado. El servidor verifica que las transacciones de entrada son solicitudes al controlador para el que se inicia el servidor. IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste RCLDDP RCLDDP Propósito La sentencia RCLDDP define una lista de nombres de controlador de dispositivo protegidos para que el conjunto de datos relacionado con ellos no sea eliminado por la función de reinicio y limpieza. RCLDDP se define en el miembro de la biblioteca EQQPARM tal y como se especifica con el parámetro DDPRMEM de la sentencia RCLOPTS. Formato RCLDDP , DDNAME( lista de nombres de controladores de dispositivo ) Parámetros DDNAME(lista de nombres de controladores de dispositivo) Define la lista de nombres de controladores de dispositivo protegidos. Capítulo 1. Definición de sentencias de inicialización 135 RCLDSNP RCLDSNP Propósito La sentencia RCLDSNP define una lista de nombres de conjuntos de datos protegidos que no son eliminados por la función de reinicio y limpieza. RCLDSNP se define en el miembro de la biblioteca EQQPARM tal y como se especifica con el parámetro DSNPRMEM de la sentencia RCLOPTS. Formato , RCLDSNP DSNAME( lista de nombres de conjuntos de datos ) Parámetros DSNAME (lista de nombres de conjuntos de datos) Define la lista de nombres de conjuntos de datos protegidos. Puede usar un asterisco (*) como carácter comodín para coincidencias parciales, tal y como se explica para la palabra clave RCLOPTS DSNPROT. 136 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste RCLOPTS RCLOPTS Propósito La sentencia RCLOPTS define todas las opciones usadas por Tivoli Workload Scheduler for z/OS durante las funciones de reinicio y limpieza. Sólo la usa el controlador. RCLOPTS se define en el miembro de la biblioteca EQQPARM tal y como se especifica con el parámetro PARM de la sentencia JCL EXEC. Nota: Debido a que en algunos casos EQQCLEAN puede suprimir un conjunto de datos por error, es aconsejable proteger los conjuntos de datos críticos mediante los parámetros RCLOPTS (DDPROT, DDPRMEM, DSNPROT, DSNPRMEM) o la salida EQQUXCAT. Formato RCLOPTS ‘ OPC’ Info de la tarjeta de trabajo CLNJOBCARD( ) EQQCL Nombre de trabajo CLNJOBPX( DSTDEST( Destino OPC ) ) DSTRMM( NO YES DDPRMEM( nombre de miembro ) ) DSNPRMEM( nombre de miembro ) DDNOREST( lista de controladores de dispositivo ) DDNEVER( lista de controladores de dispositivo ) DDALWAYS( Lista de controladores de dispositivo ) DDPROT( lista de controladores de dispositivo ) DSNPROT( | ) DSTCLASS(destino:clase) IMMEDLOGIC( | Lista DSN FIRSTSTEP BESTSTEP ) JOBLOGRETRIEVAL( ONDEMAND ONERROR ) RESTARTINFORETRIEVAL( ONDEMAND ONERROR SKIPINCLUDE(nombre de miembro) ) Capítulo 1. Definición de sentencias de inicialización 137 RCLOPTS STEPLIB(dsname) STEPRESCHK( YES NO ) Parámetros CLNJOBCARD(info de la tarjeta de trabajo|’OPC’) Define la tarjeta de trabajo que debe ser usada por el controlador al crear trabajos de limpieza autónomos. La tarjeta de trabajo predeterminada es la siguiente: //nombretrabajo JOB 'OPC' donde el nombre de trabajo se crea desde el valor CLNJOBPX combinando el prefijo y un número alfanumérico secuencial (por ejemplo EQQCL0005). Si necesita cambiar ’OPC’ con información de cuenta, puede usar la palabra clave CLNJOBCARD que sustituirá ’OPC’ con el valor especificado. Es opcional y el valor predeterminado es ’OPC’. La serie puede tener hasta 40 caracteres. No la use para establecer el emisor del trabajo de limpieza autónoma. Para esa tarea, consulte el parámetro RUSER de la salida de envío de trabajo. CLNJOBPX(nombre de trabajo|EQQCL) Define el prefijo del nombre de trabajo que debe usarse para la limpieza autónoma. Es opcional y el valor predeterminado es EQQCL. Si se especifica, debe tener cinco caracteres, de lo contrario se usa el valor predeterminado. Para realizar seguimiento correctamente al trabajo de limpieza autónomo en una conexión DASD,el conjunto de datos SU/RE debe definirse siempre. DSTDEST(destino OPC) Define el destino requerido en el JCL para crear una copia de salida de sistema para el almacén de datos. Su valor debe ser igual al al parámetro SYSDEST del almacén de datos de la sentencia DSTOPTS. El valor DSTDEST debe reservarse para ser usado por el planificador. Si la sentencia JES2 DESTDEF especifica NODENAME=REQUIRED, entonces el destino especificado en el parámetro DSTDEST debe ser definido como JES2. Puede definirlo dinámicamente como JES mediante el siguiente mandato: $ADD DESTID(XXXXXXXX),DEST=XXXXXXXX donde XXXXXXXX es el destino especificado en el parámetro DSTDEST. Si JES2 DESTDEF especifica NODENAME=OPTIONAL, entonces el destino definido en DSTDEST no necesita ser especificado. DSTRMM(YES|NO) Si especifica YES, se activa Removable Media Manager (RMM) y la limpieza usa RMM API contra volúmenes de cinta definidos a RMM. DDPRMEM(nombre de miembro) Cuando se especifica, contiene el nombre del miembro PDS de la biblioteca de parámetros que muestra los nombres de controlador de dispositivo protegidos. La sintaxis del miembro es la siguiente: v RCLDDP 138 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste RCLOPTS v DDNAME (lista de nombres de controladores de dispositivo) DDPRMEM y DDPROT se excluyen mutuamente. Puede renovarse usando el mandato MODIFY: /F procname, PROT(DD=nombre) donde procname es el nombre de procedimiento JCL de Tivoli Workload Scheduler for z/OS. DSNPRMEM (nombre de miembro) Cuando se especifica, contiene el nombre del miembro PDS de la biblioteca de parámetros que muestra los nombres de conjuntos de datos protegidos. La sintaxis dentro del miembro es la siguiente: v RCLDSNP v DSNAME (lista de nombres de conjuntos de datos) Puede usar * (asterisco) como carácter comodín para coincidencias parciales tal y como se explica para la palabra clave DSNPROT. DSNPRMEM y DSNPROT se excluyen mutuamente. Puede renovar la lista DSN cambiando el nombre de miembro DSNPRMEM con el mandato MODIFY: /F procname, PROT(DS=nombre) donde procname es el nombre de procedimiento JCL de Tivoli Workload Scheduler for z/OS. DDNOREST(Lista de controladores de dispositivo) Define la lista de nombres de controlador de dispositivo que hacen que un paso no sea reiniciable. Esta palabra clave es opcional y válida sólo para el Reinicio de paso y se ignora para el Reinicio de trabajo. DDNEVER(Lista de controladores de dispositivo) Define la lista de nombres de controlador de dispositivo que hacen que un paso no pueda volver a ejecutarse nunca. Esta palabra clave es opcional y válida sólo para el Reinicio de paso y se ignora para el Reinicio de trabajo. DDALWAYS(Lista de controladores de dispositivo) Define la lista de nombres de controlador de dispositivo que hacen que un paso pueda volver a ejecutarse siempre. Esta palabra clave es opcional y válida sólo para el Reinicio de paso y se ignora para el Reinicio de trabajo. DDPROT(Lista de controladores de dispositivo) Define la lista de nombres de controlador de dispositivo que identifican los conjuntos de datos protegidos. Es opcional. DSNPROT(Lista DSN) Palabra clave opcional que define la lista de nombres de conjuntos de datos protegidos de una eliminación no intencionada. Los conjuntos de datos especificados en esta lista serán excluidos de la lista de acción de limpieza (verá estos conjuntos de datos marcados como X, excluidos, en el panel ISPF mostrando los conjuntos de datos que deben eliminarse). Puede usar el asterisco (*) como carácter comodín para coincidencias parciales, siempre que lo especifique como el último carácter del nombre de conjunto de datos. Los caracteres que siguen al asterisco serán ignorados. Por ejemplo, para proteger el nombre de conjunto de datos MYDSN.DATASET y todos los GDG con raíz MYGDG.ROOT, puede especificar lo siguiente: DSNPROT (MYDSN.DATASET,MYGDG.ROOT*) Si especifica: DSNPROT (P*.PROD.FILE) Capítulo 1. Definición de sentencias de inicialización 139 RCLOPTS todos los archivos que comiencen con la letra P serán tenidos en cuenta, independientemente de lo especificado en el resto del nombre de conjunto de datos. Obtendrá el mismo resultado que si especifica DSNPROT (P*). El resultado será que todos los nombres de conjuntos de datos GDG MYGDG.ROOT.GnnnnVnn quedarán protegidos además de el nombre de conjunto de datos MYDSN.DATASET. DSTCLASS(destino:clase) Cuando necesite tener una configuración con el subsistema del almacén de datos y el comprobador de seguimiento con la tarea JCC activa en la misma imagen de sistema z/OS, podrían producirse problemas de compatibilidad si las opciones de la tarea JCC exigen que Tivoli Workload Scheduler for z/OS elimine los conjuntos de datos de la salida SYSOUT después del análisis habitual. Esto es porque la tarea JCC también puede eliminar la copia SYSOUT duplicada creada para el almacén de datos antes de que se haya almacenado con éxito. En esta configuración específica, para evitar este problema y mejorar el rendimiento de JCC que estaría explorando dos veces los mismos conjuntos de datos SYSOUT, necesita proporcionar una clase JES al destino del comprobador de seguimiento que debe ser usada por la copia duplicada de los conjuntos de datos SYSOUT creados para el proceso del almacén de datos. La copia duplicada de la SYSOUT se añadirá temporalmente a esta clase hasta que el almacén de datos la recupere, la almacene y la elimine. No necesita ser una clase reservada: la única característica obligatoria es que no debe ser una de las clases especificadas en el parámetro JCC CHKCLASS. De este modo la tarea JCC nunca procesará los conjuntos de datos de salida especificados para el proceso del almacén de datos. En un sistema JES3, debe definir las DSTCLASS como HOLD=EXTWTR y TYPE=PRINT. Debe usar la misma clase para todos los comprobador de seguimientoes y sistemas, ya que normalmente es más sencillo y está menos expuesto a situaciones potenciales de error. Esta sugerencia se convierte en requisito si la configuración se realiza en un complejo MAS (servidor de autenticación maestro) de JES MAS o si el usuario especificó sentencias NJEpara direccionar la salida después de la ejecución del trabajo. El valor de la palabra clave se especifica en pares; el destino del comprobador de seguimiento seguido de la clase JES. Los valores de destino y los pares de clases se especifican como en el siguiente formato: Dest1:Class1 donde Dest1 es el destino del comprobador de seguimiento tal y como se especifica en la sentencia ROUTOPTS y Class1 es la clase JES que debe usarse para los conjuntos de datos SYSOUT duplicados para el proceso del almacén de datos. Los valores de destino y de clase van separados por dos puntos, mientras que los pares de destino y de clase van separados por una coma. Los destinos especificados deben ser consistentes con los definidos en la sentencia ROUTOPTS. El destino del comprobador de seguimiento de 8 asteriscos (********) identifica el sistema donde se ejecutan el controlador y un comprobador de seguimiento local. Nota: Este mecanismo permite a JCC y al almacén de datos trabajar correctamente al mismo tiempo pero no evita que la tarea JCC elimine la 140 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste RCLOPTS SYSOUT de usuario de los trabajos. Por lo tanto, la SYSOUT de usuario, después de ser comprobada por JCC, no aparecerá con el resto de la salida de sistema. Cuando el planificador selecciona una operación para que sea enviada, se comprueban los valores DSTCLASS() para determinar si debe insertarse un parámetro CLASS= en la sentencia JCL de salida que se añade automáticamente al JCL original. Recuerde especificar un par con el formato ********:X para obtener el parámetro CLASS=X generado para trabajos planificados en el mismo procesador que el controlador, es decir, en estaciones de trabajo de sistemas con destino en blanco. Por ejemplo: RCLOPTS DSTCLASS(********:Q,TRKRSYS1:Q,TRKRSYS2:Q) Este ejemplo especifica una lista de pares adecuada para un servidor de autenticación maestro JES2 de 2 miembros, con un comprobador de seguimiento en el mismo LPAR donde se ejecuta el controlador y otro comprobador de seguimiento en el otro LPAR. Los destinos del comprobador de seguimiento son TRKRSYS1 y TRKRSYS2 respectivamente. Si omite el primer par, los trabajos planificados en estaciones de trabajo con destinos en blanco serán enviados sin añadir CLASS=Q a la sentencia de salida generada. IMMEDLOGIC(BESTSTEP|FIRSTSTEP) Define la lógica para ejecutar acciones de limpieza cuando una operación termina en error y el tipo de limpieza es Inmediata. FIRSTSTEP significa que las acciones de limpieza son realizadas considerando el primer paso como paso de inicio. Sin embargo, si las acciones de recuperación automática sugieren un paso de reinicio, éste será considerado el paso de inicio. BESTSTEP significa que las acciones de limpieza son realizadas considerando el mejor paso como paso de inicio. Sin embargo, si las acciones de recuperación automática sugieren un paso de reinicio, éste será considerado el paso de inicio. Para obtener detalles sobre cómo se determina el mejor paso, consulte Gestión de la carga de trabajo. Nota: Si especifica BESTSTEP y vuelve a ejecutar un trabajo con Limpieza=Inmediata sin usar la vía de acceso Reinicio y Reinicio Paso-Limpieza, es posible que las acciones de limpieza no sean coherentes con el intervalo de paso. | | | | JOBLOGRETRIEVAL(ONERROR|ONDEMAND) Este parámetro define la política de recuperación de registros de trabajos para las operaciones que se ejecutan en estaciones de trabajo automáticas que producen un registro de trabajos de MVS. Los valores válidos son estos: | | | ONDEMAND El valor predeterminado. El usuario debe realizar una solicitud explícitamente para recuperar el registro de trabajos. | | | | ONERROR Después de que un trabajo se ejecuta y acaba en error, el registro de trabajos se recupera y envía automáticamente. Los cambios manuales en el error no desencadenan el proceso de recuperación para empezar. | | | | RESTARTINFORETRIEVAL(ONERROR|ONDEMAND) Para ejecutar acciones de reinicio y limpieza en una operación, por ejemplo el reinicio de pasos o la limpieza de conjuntos de datos, la información de reinicio debe extraerse de los registros de trabajos. Este parámetro define la Capítulo 1. Definición de sentencias de inicialización 141 RCLOPTS | | | política de recuperación de información de reinicio para las operaciones que se ejecutan en estaciones de trabajo automáticas que producen un registro de trabajos de MVS. | | | | | ONDEMAND El valor predeterminado. El proceso de recuperación de información de reinicio se inicia en cuanto una acción de reinicio y limpieza, que requiere la información de reinicio, la solicita específicamente un usuario o se solicita automáticamente. | | | | ONERROR El proceso de recuperación de información de reinicio se inicia cuando una operación acaba en error. Los cambios manuales en el error no desencadenan el proceso de recuperación para empezar. SKIPINCLUDE(nombre de miembro) Durante el proceso de adaptación del JCL, el paso previo EQQCLEAN y las sentencias //TIVDSTxx OUTPUT son añadidos al comienzo del JCL antes de la primera sentencia EXEC. También se insertan antes de las INCLUDE que pueden preceder a la primera sentencia EXEC, a menos que aparezcan en la lista SKIPINCLUDE. En este caso, la inserción del paso previo y de otras sentencias se realiza después de las INCLUDE mostradas por esta palabra clave. SKIPINCLUDE muestra el nombre del miembro PDS de la biblioteca de parámetros que contiene la lista de sentencias INCLUDE que deben saltarse en el proceso de adaptación del JCL. Recuerde que la exploración del JCL que debe enviarse se detiene en la primera sentencia INCLUDE que precede a la primera sentencia EXEC, la cual no aparece en la lista RCLSKIP INCLNAME(). Por lo tanto, si su JCL tiene sentencias OUTPUT con JESDS=ALL, las cuales se colocan DESPUÉS de una INCLUDE, dicha INCLUDE debe aparecer en la lista INCLNAME(). Aparecerá la siguiente sentencia OUTPUT y no se insertará una sentencia TIVDSTAL OUTPUT superflua en el JCL. Debería usar SKIPINCLUDE si tiene un JCL donde la primera EXEC va precedida de varias INCLUDE que contengan sentencias de JCL que no puedan colocarse después de una sentencia EXEC y que no contengan sentencias EXEC. Ejemplos de sentencias de JCL que no pueden colocarse después de una sentencia EXEC son las sentencias JOBLIB y JOBCAT, y sentencias OUTPUT con la palabra clave JESDS. Este tipo de INCLUDE provoca una colocación incorrecta de paso EQQCLEAN si usa JCL normal (el JCL ampliado no contiene normalmente INCLUDE, a menos que lo añada intencionadamente antes de volver a enviar el JCL). Puede evitar errores de JCL provocados por la colocación incorrecta de EQQCLEAN insertando estas INCLUDE en el miembro PDS definido con SKIPINCLUDE. Si una sentencia INCLUDE contiene ambas sentencias de JCL, que no pueden colocarse después de una sentencia EXEC, y una sentencia EXEC, debe dividirse en dos INCLUDE distintas. Por ejemplo, si una sentencia INCLUDE contiene las sentencias JOBLIB y EXEC, debe dividirse en dos INCLUDE distintas: una con JOBLIB y la otra con EXEC. La sintaxis que debe usarse en el miembro PDS se describe en la sección de la sentencia RCLSKIP. 142 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste RCLOPTS Para renovar SKIPINCLUDE, escriba el mandato de operador MODIFY siguiente: /F procname,SKIPINC(nombremiembro) donde procname es el nombre de procedimiento JCL de Tivoli Workload Scheduler for z/OS. STEPLIB (dsname) Define el nombre del conjunto de datos que debe ser sobrescrito por el especificado en la tarjeta del controlador de dispositivo //STEPLIB de su procedimiento EQQCLEAN. Esta palabra clave es opcional, pero si la especifica, deberá de definir siempre una STEPLIB en su procedimiento EQQCLEAN, como una ficticia de controlador de dispositivo. Si no se especifica este parámetro, no se realizará ningún cambio al procedimiento EQQCLEAN. STEPRESCHK (NO|YES) Especifica la posibilidad de seleccionar un intervalo de reinicio de paso que anule temporalmente la lógica de producto (por ejemplo, un posible paso de reinicio podría ser un paso no reiniciable). Si especifica NO, no se realiza la comprobación de lógica de producto. El valor predeterminado es YES. Este tipo de comportamiento puede provocar errores de JCL y es responsabilidad del usuario decidir cuándo es necesaria la alteración temporal. Capítulo 1. Definición de sentencias de inicialización 143 RCLSKIP RCLSKIP Propósito La sentencia RCLSKIP muestra las INCLUDE que desea mantener al comienzo de un JCL cuando es adaptado por la función de reinicio y limpieza. Debe grabar RCLSKIP en el miembro PDS cuyo nombre es especificado por la palabra clave RCLOPTS SKIPINCLUDE (para obtener detalles sobre SKIPINCLUDE, consulte en la página 142). Formato , RCLSKIP INCLNAME( nombre del miembro ) Parámetros INCLNAME (nombre del miembro) Muestra los nombres de miembro especificados en la palabra clave MEMBER=palabra clave de una o más sentencias INCLUDE. Puede usar un asterisco (*) como carácter comodín para coincidencias parciales del modo siguiente. Como el último carácter Por ejemplo, si especifica ABC* todos los INCLUDE cuyos nombres comiencen con ABC se dejarán en la parte superior del JCL. Como el primer carácter Por ejemplo, si especifica *ABC todos los INCLUDE cuyos nombres terminen con ABC se dejarán en la parte superior del JCL. Como el único carácter Si especifica sólo el asterisco (*), todos los INCLUDE se dejarán en la parte superior del JCL. Como comodín puede utilizar el asterisco sólo una vez. Por ejemplo, si especifica: RCLSKIP INCLNAME(*A*B) Todos los INCLUDE cuyos nombres terminen con A*B se considera que coinciden con los criterios de búsqueda, porque el segundo asterisco se considera un carácter normal. Si especifica: RCLSKIP INCLNAME(A*B) Todos los INCLUDE cuyos nombres empiecen con A se considera que coinciden con los criterios de búsqueda, porque el asterisco se considera el último carácter. Si especifica: RCLSKIP INCLNAME(JOBINCL,ZZZ*) la INCLUDE llamada 'JOBINCL' y todas las INCLUDE cuyos nombres comiencen por ZZZ (por ejemplo, ZZZ1, ZZZABC, etc.) se considera que coinciden con los criterios de búsqueda. 144 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste RCLSKIP El paso previo EQQCLEAN será añadido sólo después de estas INCLUDE por el proceso de adaptación de JCL (para obtener detalles sobret SKIPINCLUDE, consulte en la página 142). Capítulo 1. Definición de sentencias de inicialización 145 RESOPTS RESOPTS Propósito La sentencia RESOPTS define las opciones de recursos especiales que usa el controlador para procesar operaciones preparadas y sucesos con recursos especiales. RESOPTS se define en el miembro de la biblioteca EQQPARM tal y como se especifica con el parámetro PARM de la sentencia JCL EXEC. Formato RESOPTS 30 número minutos CONTENTIONTIME( ) DYNAMICADD( YES EVENT OPER NO ) DYNONCOMPLETE( NOCHANGE YES NO RESET ) LOOKAHEAD( 0 porcentaje ) ONCOMPLETE( NOCHANGE YES NO RESET ) ONERROR( FREESR FREESRS FREESRX KEEPSR ) Parámetros CONTENTIONTIME(número de minutos|30) CONTENTIONTIME determina cuánto tiempo permanece una operación en la cola de espera para un recurso especial antes de que Tivoli Workload Scheduler for z/OS emita el mensaje EQQQ515W. Especifique el número de minutos (de 1 a 9999) que debe esperar una operación antes de que Tivoli Workload Scheduler for z/OS emita el mensaje EQQQ515W. Cuando se emite, el mensaje no se repita para el mismo recurso especial y la misma operación, aunque Tivoli Workload Scheduler for z/OS puede emitir más de un mensaje para una operación si está en más de una cola de espera. Nota: También debe especificar una acción de alerta para la contención de recursos en la sentencia ALERTS o de lo contrario no se emitirá el mensaje. La sentencia ALERTS se describe en “ALERTS” en la página 10. DYNAMICADD(EVENT|OPER|NO|YES) Si no se define un recurso especial en el archivo de ampliación del plan actual o en la base de daros de recursos especiales, DYNAMICADD determina si Tivoli Workload Scheduler for z/OS crea un recurso especial en respuesta a 146 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste RESOPTS una solicitud de asignación desde una operación preparada o a un suceso de recursos creado mediante la subrutina EQQUSIN o EQQUSINS, el mandato SRSTAT TSO, la solicitud API CREATE o una notificación RODM. Especifique YES, que es el valor predeterminado, siTivoli Workload Scheduler for z/OS debe crear un recurso especial en el plan actual. Tivoli Workload Scheduler for z/OS usa valores predeterminados para crear el recurso cuando no se actualiza la base de datos de recursos especiales. Cuando crea el recurso, Tivoli Workload Scheduler for z/OS selecciona valores en este orden: 1. Valores proporcionados por la operación o suceso de asignación. Una operación puede especificar una cantidad, un suceso puede especificar cantidad, disponibilidad y desviación. 2. Valores predeterminados de Tivoli Workload Scheduler for z/OS. Especifique NO si Tivoli Workload Scheduler for z/OS no debe crear dinámicamente un recurso especial. Si una operación intenta asigna el recurso especial, recibe una anomalía de asignación y la operación permanece en estado A o R con estado ampliado de X. Si se recibe un suceso de recursos para el recurso sin definir, se graba un mensaje de error en el registro de mensajes del controlador. Especifique EVENT si Tivoli Workload Scheduler for z/OS debe crear un recurso especial en el plan actual sólo es repuesta a un suceso de recursos. Los recursos no son creados por asignaciones de operaciones. Pero si la palabra clave CREATE de un mandato SRSTAT tiene el valor NO, no se crea el recurso especial. Especifique OPER si Tivoli Workload Scheduler for z/OS debe crear un recurso especial en el plan actual sólo es repuesta una solicitud de asignación desde una operación preparada. Los recursos no son creados por sucesos. Un recurso creado dinámicamente tiene estos valores si no se encuentra ninguna descripción en la base de datos: Recurso especial El nombre especificado por la operación de asignación o el suceso de recursos. Texto En blanco. ID de grupo Rec Espec En blanco. Hiperbatch No. Usado para Control. En error En blanco.Si se produce un error, Tivoli Workload Scheduler for z/OS usa el valor especificado en los detalles de operación o, si este campo también está en blanco, el valor de la palabra clave ONERROR de RESOPTS. Disponible El valor especificado por un suceso (Y o N) o en blanco. Cantidad El valor especificado por un suceso (1 a 999999) o en blanco. Capítulo 1. Definición de sentencias de inicialización 147 RESOPTS Desviación El valor especificado por un suceso (-999999 a 999999) o en blanco. Valores predeterminados El recurso tiene estos valores que son predeterminados para cantidad y disponibilidad: Cantidad 1. O la cantidad especificada por una operación de asignación. La cantidad predeterminada aumenta automáticamente si se produce contención, pero sólo para recursos creados dinámicamente. Disponible Sí. Intervalos No se crean intervalos. Estaciones de trabajo El recurso tiene el valor predeterminado *, lo cual significa todas las estaciones de trabajo. Las operaciones de todas las estaciones de trabajo pueden asignar el recurso. Consulte también la palabra clave DYNAMICADD de BATCHOPT en la página 29, la cual controla la creación dinámica de recursos especiales durante la planificación. Notas: 1. Si Tivoli Workload Scheduler for z/OS se suscribe a una clase u objeto RODM para un recurso que no existe en el plan actual, el suceso creado desde los datos devueltos por RODM provoca una adición dinámica del recurso si DYNAMICADD tiene el valor YES o EVENT. 2. Se aconseja encarecidamente que, si se usa la característica de adición dinámica de recursos especiales, debido a que un recurso especial añadido dinámicamente no coincide casi nunca con los criterios citados anteriormente de ser eliminados automáticamente, se especifique DYNAMICDEL(YES) en la sentencia BATCHOPT del trabajo por lotes DP. DYNONCOMPLETE(YES|NO|RESET|NOCHANGE) Esta palabra clave define el valor con que se restablece la disponibilidad global de los recursos especiales cuando termina la operación que usa esos recursos. Sólo se aplica a recursos especiales añadidos dinámicamente. Este valor lo usa Tivoli Workload Scheduler for z/OS sólo si el campo Cambio al completar está en blanco en la definición de la operación y la definición de recursos especiales. Puede especificar estos valores: NOCHANGE No se realiza ninguna acción. Es el valor predeterminado. YES La disponibilidad global del recurso especial se restablece como YES. NO La disponibilidad global del recurso especial se restablece como NO. RESET La disponibilidad global del recurso especial se restablece como en blanco. LOOKAHEAD(percentaje|0) Especifique esta palabra clave si desea que Tivoli Workload Scheduler for z/OS compruebe antes de iniciar una operación si hay suficiente tiempo antes de que el recurso deje de estar disponible. Especifique la palabra clave como un 148 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste RESOPTS porcentaje de la duración estimada. Por ejemplo, si no desea que Tivoli Workload Scheduler for z/OS inicie una operación a menos que esté disponible el recurso especial requerido para toda la duración estimada, especifique 100. Especifique 50 si debe quedar al menos la mitad de la duración estimada hasta que el recurso deje de estar disponible. Si especifica LOOKAHEAD(0), que es el valor predeterminado, la operación se inicia si está disponible el recurso especial, incluso si va a dejar de estar disponible pronto. Tivoli Workload Scheduler for z/OS usa esta palabra clave sólo si se usa el recurso espacial para tener control. ONCOMPLETE(YES|NO|RESET|NOCHANGE) Esta palabra clave define el valor con que se restablece la disponibilidad global de los recursos especiales cuando termina la operación que usa esos recursos. Este valor lo usa Tivoli Workload Scheduler for z/OS sólo si el campo Cambio al completar está en blanco en la definición de la operación y la definición de recursos especiales. Puede especificar estos valores: NOCHANGE No se realiza ninguna acción. Es el valor predeterminado. YES La disponibilidad global del recurso especial se restablece como YES. NO La disponibilidad global del recurso especial se restablece como NO. RESET La disponibilidad global del recurso especial se restablece como en blanco. Si usa un valor distinto del predeterminado NOCHANGE, entonces se restablece la disponibilidad global de todos los recursos especiales cada vez que termina una operación que los use. ONERROR(FREESRS|FREESRX|KEEPSR|FREESR) Esta palabra clave define cómo se manejan los recursos especiales cuando se establece una operación que usa recursos especiales como terminada en error. El valor de la palabra clave ONERROR lo usa Tivoli Workload Scheduler for z/OS sólo si el campo ONERROR de un recurso en blanco del plan actual está en blanco y el valor Mantener en error en los detalles de operación también se deja en blanco. Puede especificar estos valores: FREESR Tivoli Workload Scheduler for z/OS libera todos los recursos especiales asignados por la operación. FREESRS Tivoli Workload Scheduler for z/OS libera los recursos especiales compartidos y conserva exclusivamente los recursos especiales asignados. FREESRX Tivoli Workload Scheduler for z/OS libera exclusivamente los recursos especiales asignados y conserva los recursos especiales compartidos. KEEPSR No se libera ningún recurso especial asignado por la operación. Tivoli Workload Scheduler for z/OS libera o conserva sólo la cantidad asignada por la operación anómala. Otras operaciones pueden asignar un recurso especial si está disponible la cantidad requerida. Los recursos especiales conservados cuando una operación termina en error no son liberados hasta que la operación recibe el estado de terminada. Capítulo 1. Definición de sentencias de inicialización 149 RESOPTS Puede especificar excepciones para recursos individuales en la base de datos de recursos especiales y en el plan actual. Ejemplos RESOPTS CONTENTIONTIME(10) DYNAMICADD(YES) ONERROR(FREESRS) LOOKAHEAD(200) 1 2 3 4 En este ejemplo de una sentencia RESOPTS: 150 1 Tivoli Workload Scheduler for z/OS emite el mensaje EQQQ515W si una operación ha esperado 10 minutos para asignar un recurso especial. 2 Si no se define un recurso especial en el plan actual, Tivoli Workload Scheduler for z/OS crea el recurso especial en respuesta a una solicitud de asignación desde una operación preparada o a un suceso de recursos especiales. 3 Los recursos especiales compartidos se liberan si la operación que asigna termina en error. Sólo se conservan los recursos especiales asignados 4 Si queda menos de dos veces (200%) la duración estimada de una operación antes de que el recurso vaya a dejar de estar disponible, Tivoli Workload Scheduler for z/OS no iniciará la operación. IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste RESOURCE RESOURCE Propósito La sentencia RESOURCE identifica los recursos especiales para los que se necesitan informes. Puede especificar más de una sentencia RESOURCE. las sentencias RESOURCE se usan cuando un trabajo de planificación diaria solicita informes de recursos especiales. Un recurso especial se incluye en un informe si existe y su nombre coincide con un valor en una sentencia RESOURCE. Si no se especifica RESOURCE, no se producen informes. Las sentencias RESOURCE se especifican en el miembro de la biblioteca de parámetros que contiene la sentencia BATCHOPT. Formato , RESOURCE FILTER( nombre de recurso especial ) Parámetros FILTER(nombre de recurso especial,...,nombre de recurso especial) Los valores FILTER identifican recursos especiales que Tivoli Workload Scheduler for z/OS incluye cuando un trabajo de planificación diaria solicita informes de utilización de recursos planificados o reales. Los valores se comparan con los recursos especiales conocidos en el momento de la planificación. Si el nombre de un recurso especial coincide con un valor de filtro, se informa de él. Un recurso especial se selecciona sólo una vez si coincide con más de un valor de filtro, incluso si los valores están en sentencias RESOURCE diferentes. Los valores tienen 1–44 caracteres y no debe contener espacios en blanco incrustados. Puede especificar asterisco (*) y porcentaje (%) en cualquier parte de un valor. Un asterisco coincide con cualquier carácter y cualquier número de caracteres. Un signo de porcentaje coincide con cualquier carácter 1. Ejemplos RESOURCE FILTER(TAPE*,34%%) RESOURCE FILTER(*80) 1 2 En este ejemplo de sentencias RESOURCE, se generan informes para recursos especiales cuyos nombres contienen: 1 TAPE como los primeros 4 caracteres seguido de cualquier número de caracteres, y 34 como los dos primeros caracteres seguido de 2 caracteres más. 2 80 como los últimos o únicos caracteres. Capítulo 1. Definición de sentencias de inicialización 151 RODMOPTS RODMOPTS Propósito Las sentencias RODMOPTS son usadas por un controlador para supervisar recursos especiales mediante Resource Object Data Manager (RODM). Puede usar RODM para realizar seguimiento al estado de los recursos reales usados por operaciones de Tivoli Workload Scheduler for z/OS. Las sentencias RODMOPTS se especifican en el miembro de la biblioteca EQQPARM especificado en la palabra clave RODMPARM de OPCOPTS. Se necesita una sentencia RODMOPTS para cada campo de cada recurso que desee supervisar. Notas: 1. Los nombres de clases, objetos y campos RODM son sensibles a mayúsculas y minúsculas. Asegúrese de preservar el caso al especificar sentencias RODMOPTS en la biblioteca de parámetros. Además, si un nombre no contiene caracteres alfanuméricos o nacionales, debe adjuntar el nombre en comillas. 2. Si IBM Tivoli Workload Scheduler for z/OS se suscribe a RODM para un recurso que no existe en el plan actual y la palabra clave DYNAMICADD de RESOPTS tiene el valor YES o EVENT, el suceso creado desde los datos devueltos por RODM provoca una adición dinámica del recurso. DYNAMICADD se describe en la página 146. Formato RODMOPTS DESTINATION( OPCFIELD( identificador de destino del comprobador de seguimiento AVAILABLE DEVIATION QUANTITY RODMCLASS( ) OPCRESOURCE( nombre de clase RODM nombre de recurso especial ) RODMFIELD( ) ) nombre de campo RODM ) RODMLOST( LAST RESET valor de campo RODMOBJECT( RODMRM2XE( YES NO RODMUSER( USERID nombre de objeto RODM ) ) RODMSYSTEM( nombre de subsistema RODM ) ) ) , TRANSLATE( C'valor desde' N'valor desde' X'valor desde' G'*' : C'valor hasta' N'valor hasta' X'valor hasta' ) Parámetros DESTINATION(identificador de destino del comprobador de seguimiento) Especifica el identificador de destino de un comprobador de seguimiento iniciado en la misma imagen de z/OS que el subsistema RODM. Es el mismo nombre que se especifica en la sentencia ROUTOPTS. 152 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste RODMOPTS No especifique DESTINATION si el comprobador de seguimiento y el controlador son iniciados en el mismo espacio de direcciones. OPCFIELD(AVAILABLE|DEVIATION|QUANTITY) Especifique el nombre de campo en el recurso especial que desee supervisar mediante RODM. Cuando RODM notifica un cambio, Tivoli Workload Scheduler for z/OS actualiza: AVAILABLE El campo Available (disponible) en el recurso. Este valor anula temporalmente los valores predeterminados y de intervalo. QUANTITY El campo Quantity (cantidad) en el recurso. Este valor anula temporalmente los valores predeterminados y de intervalo. DEVIATION El campo Deviation (desviación). Use este campo para realizar un ajuste temporal a la cantidad. IBM Tivoli Workload Scheduler for z/OS añade cantidad y desviación juntas para decidir la cantidad de operaciones que puede asignar. Por ejemplo, si la cantidad es 10 y la desviación es -3, las operaciones pueden asignar hasta 7 del recurso. OPCRESOURCE(Nombre de recurso especial) Especifique el nombre del recurso especial que desee supervisar mediante RODM. RODMCLASS(nombre de clase RODM) Tivoli Workload Scheduler for z/OS puede suscribirse a un campo de clase RODM o a un campo de objeto RODM para supervisar un recurso especial. Especifique el nombre de un campo de clase RODM usado para supervisar el recurso especial. También puede especificar el nombre de la clase en la que está el objeto en caso de que supervise el recurso mediante un campo de objeto. RODMFIELD(nombre de campo RODM) Especifique el nombre de campo en la clase RODM o el objeto RODM usado para supervisar el campo en el recurso especial. RODMLOST(RESET|valor de campo|LAST) Esta palabra clave determina el valor que Tivoli Workload Scheduler for z/OS establece para el campo de recurso especial cuando no es posible establecer comunicación con el subsistema RODM. Si el controlador no puede comunicarse con un subsistema RODM porque no responde un comprobador de seguimiento o RODM, emite un mensaje de aviso. El controlador actualiza todos los recursos especiales que se suscriben al subsistema RODM perdido, según el valor de RODMLOST. Especifique RESET si Tivoli Workload Scheduler for z/OS usa el valor producido por la planificación diaria para la hora actual. Especifique LAST si Tivoli Workload Scheduler for z/OS usa el último valor conocido. Si desea que Tivoli Workload Scheduler for z/OS establezca un valor específico, especifique ese valor para RODMLOST. El valor que puede especificar depende del nombre de campo en la palabra clave OPCFIELD. Puede especificar: AVAILABLE Un valor de carácter Y o N QUANTITY Un valor entero entre 1–999999 DEVIATION Un valor entero entre -999999–999999. Capítulo 1. Definición de sentencias de inicialización 153 RODMOPTS RODMOBJECT(nombre de objeto RODM) Especifique el nombre de un objeto RODM si usa un campo de objeto para supervisar el recurso especial. El nombre de objeto debe existir en la clase especificada en RODMCLASS. RODMRM2XE(NO|YES) Use esta palabra clave para enviar un mensaje WTO especial EQQRM2XE a la consola de z/OS cuando falla la conexión a un objeto RODM. Este mensaje aparece con uno de los siguientes mensajes emitido a EQQMLOG: EQQRM24, EQQRM2, EQQRM26 o EQQRM27. El valor predeterminado es YES. Especifique NO para evitar enviar el mensaje. RODMSYSTEM(nombre de subsistema RODM) Identifica el subsistema RODM al que Tivoli Workload Scheduler for z/OS envía solicitudes de suscripción. Es el nombre del espacio de direcciones al que desea que se conecte Tivoli Workload Scheduler for z/OS. Puede especificarlo en el parámetro &NAME del procedimiento de inicio de RODM. Si se omite el parámetro &NAME, el nombre predeterminado es el nombre de tarea iniciada de RODM. RODMUSER (identificador de usuario) Define el identificador de usuario usado por Tivoli Workload Scheduler for z/OS para conectarse al sistema RODM. Especifíquelo cuando el parámetro RODM SEC_CLASS esté establecido como *TSTRODM. El valor predeterminado es en blanco. TRANSLATE(valor desde:valor hasta,......,valor desde:valor hasta) Especifique esta palabra clave si los valores para el campo RODM son distintos a los del campo de recursos especiales. Por ejemplo, un valor Y de Tivoli Workload Scheduler for z/OS puede estar representado en RODM por un valor 1. Los campos de recursos especiales tienen estos valores: AVAILABLE Un valor de carácter Y o N QUANTITY Un valor entero entre 1–999999 DEVIATION Un valor entero entre -999999–999999. Especifique un valor de campo RODM que sea traducido a un valor de campo de Tivoli Workload Scheduler for z/OS cuando Tivoli Workload Scheduler for z/OS reciba la notificación de un cambio desde RODM. Los valores de traducción están en pares separados por dos puntos. Los pares de valores van separados por una coma. Especifique: C'value' Para valores de caracteres. N'value' Para valores numéricos. X'value' Para valores hexadecimales. G'*' Para una coincidencia genérica. Un valor recibido desde RODM que no ha sido especificado en valor desde se traduce al valor hasta. Especifique la coincidencia genérica si no conoce, o no ha especificado, todos los valores que puede contener el campo RODM. Si Tivoli Workload Scheduler for z/OS recibe un valor RODM que no es un valor de campo de Tivoli Workload Scheduler for z/OS válido, se graba un mensaje en el registro de mensajes del controlador y no se cambia el campo. Si no especifica TRANSLATE, no se traducen los valores RODM. 154 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste RODMOPTS Ejemplos RODMOPTS RODMSYSTEM(RODB) DESTINATION(SYSBTRK) OPCRESOURCE(SYSB.TAPE.UNITS) OPCFIELD(AVAILABLE) RODMCLASS(z/OSSYSB_TAPE_UNITS) RODMFIELD(TAPES_ONLINE) TRANSLATE(N’0’:C’N’, N’1’:C’Y’, G’*’:C’N’) RODMLOST(Y) RODMRM2XE(NO) RODMUSER(USERID) 1 2 3 4 5 6 7 8 9 10 En este ejemplo de una sentencia RODMOPTS, RODM se usa para supervisar la disponibilidad de las unidades de cintas usadas por las operaciones de Tivoli Workload Scheduler for z/OS: 1 Tivoli Workload Scheduler for z/OS envía esta solicitud a un subsistema RODM, RODB. 2 El comprobador de seguimiento en el mismo sistema que RODB tiene el identificador de destino SYSBTRK. El controlador envía la solicitud al comprobador de seguimiento, el cual se comunica con RODB mediante la interfaz del subsistema. Se especifica RODMTASK(YES) para el comprobador de seguimiento. 3 SYSB.TAPE.UNITS es el nombre del recurso especial de Tivoli Workload Scheduler for z/OS. Representa todas las unidades de cintas en SYSB. 4 Es necesaria supervisión de RODM para el campo disponible en el recurso especial SYSB.TAPE.UNITS. 5 En RODM, las unidades de cintas en SYSB son representadas por el nombre de clase z/OSSYSB_TAPE_UNITS. 6 Tivoli Workload Scheduler for z/OS se subscribe al campo de clase TAPES_ONLINE de z/OSSYSB_TAPE_UNITS. Si el subcampo de valor de TAPES_ONLINE cambia, se les notifica a todos los suscriptores. 7 La palabra clave TRANSLATE se especifica porque este ejemplo asume que el subcampo de valor contiene sólo valores numéricos. En Tivoli Workload Scheduler for z/OS sólo se permiten los valores Y y N para el campo disponible. Tivoli Workload Scheduler for z/OS traduce 0 a N (N'0':C'N'), 1 a Y (N'1':C'Y') y el resto de valores a N (G'*':C'N') cuando RODM informa del valor de subcampo. 8 Si se pierde la comunicación con RODM, el campo disponible del recurso especial se establece como Y. 9 Es mejor que no aparezca el mensaje EQQRM2XE. 10 El planificador usa USR1 para conectar al sistema RODM. Capítulo 1. Definición de sentencias de inicialización 155 ROUTOPTS ROUTOPTS Propósito La sentencia ROUTOPTS define las opciones de direccionamiento a un controlador o un controlador en reposo. ROUTOPTS define cómo se alcanza un destino. Se utiliza un destino para representar : v Un sistema de comprobador de seguimiento conectado al controlador mediante DASD compartido, enlace SNA (VTAM) y enlaces de comunicación XCF o TCP/IP. v Un entorno definido por el usuario donde la comunicación es manejada usando la salida de iniciación de operación, EQQUX009. v Motores remotos, Tivoli Workload Scheduler for z/OS agent, y gestores de dominios dinámicos. En este caso se utilizan destinos HTTP o HTTPS. | | | | | | | | Puede especificar más de una sentencia ROUTOPTS para definir las opciones de direccionamiento, pero los destinos deben ser únicos. No especifique el mismo nombre en los parámetros DASD, USER, SNA, XCF, TCP/IP o HTTP. Si se repite un destino en una sentencia ROUTOPTS, se usa la última definición. Puede especificar un total combinado de 1000 destinos, pero no puede especificar más de 16 destinos para la palabra clave DASD. ROUTOPTS se define en el miembro de la biblioteca EQQPARM tal y como se especifica con el parámetro PARM de la sentencia JCL EXEC. Puede incluir tantos destinos como desee dentro de los paréntesis. Deben separarse con comas. Formato , ROUTOPTS DASD( destino , ) HTTP|HTTPS( destino , SNA( destino , ) TCPIP( destino , ) USER( destino , XCF( destino ) ) PULSE( 156 ) 10 frecuencia de pulso ) IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste ROUTOPTS Parámetros DASD(destino,...,destino) Esta palabra clave identifica las conexiones DASD. Cada nombre de destino es un ddname de envío/liberación en el procedimiento JCL del controlador. | | | | | HTTP|HTTPS(destino,...,destino) Define las direcciones de red de las estaciones de trabajo de agentes conectadas por HTTP, normalmente motores remotos, Tivoli Workload Scheduler for z/OS agent o gestores de dominios dinámicos. Use HTTPS para definir las conexiones HTTP como conexiones seguras de SSL. La sintaxis de cada destino es así: | | nombre de destino:’dirección IP o nombre de host’/puerto[/tipo] | Donde: | | nombre de destino El nombre asignado al destino, de hasta 8 caracteres alfanuméricos. | | | dirección IP o nombre de host El nombre de host completo o la dirección IP utilizado para comunicarse con las estaciones de trabajo del agente. | | | puerto El número de puerto usado para comunicarse con las estaciones de trabajo del agente. | | | tipo El tipo de destino HTTP es necesario sólo si se utiliza el destino para definir una estación de trabajo de motor remoto o un gestor de dominio dinámico. Puede ser uno de los siguientes: | D para un motor remoto distribuido | Z para un motor remoto z/OS | B para un gestor de dominio dinámico | | | Puede modificar, añadir o suprimir un destino HTTP o HTTPS mientras se ejecuta Tivoli Workload Scheduler for z/OS. Para obtener información detallada, consulte “Modificación de los destinos HTTP” en la página 160 PULSE(frecuencia de pulso|10) Esta palabra clave define la duración entre reconocimientos (sucesos identificadores) iniciados por los comprobador de seguimientoes. El suceso identificador describe el entorno y las opciones del sistema usados por el comprobador de seguimiento. Si el controlador no recibe un suceso identificador desde el destino durante dos intervalos de pulso consecutivos, el destino es puesto fuera de línea por el controlador. Especifique un número de minutos de 1 a 60 o especifique 0 si no es necesario reconocimiento. El valor predeterminado es 10 minutos. PULSE sólo funciona con OPC/ESA Release 3 o comprobador de seguimiento superiores y se hace efectivo cuando se han sincronizado el controlador y el comprobador de seguimiento durante el inicio. Un comprobador de seguimiento debe tener un identificador de destino sin espacios en blanco a menos que el comprobador de seguimiento y el controlador se inicien en el mismo espacio de direcciones. PULSE le permite usar el reinicio y el redireccionamiento de la carga de trabajo para comprobador de seguimiento conectados mediante DASD y para otros tipos de conexión en casos donde está disponible la conexión pero no está Capítulo 1. Definición de sentencias de inicialización 157 ROUTOPTS activo el grabador de sucesos en el destino. El proceso de reconocimiento no se realiza para destinos definidos por el usuario. Nota: La palabra clave OFFDELAY de JTOPTS se tiene en cuenta después de que una estación de trabajo se cambia a fuera de línea y antes de inicia las acciones fuera de línea. En el caso de comprobador de seguimiento conectados mediante XCF, los problemas de temporización pueden provocar conflictos entre el parámetro de pulso y las acciones de redireccionamiento fuera de línea de la estación de trabajo. SNA(destino,...,destino) Esta palabra clave identifica todas las conexiones SNA. Cada destino es el nombre de unidad lógica VTAM de un sistema de comprobador de seguimiento. Si se especifica la palabra clave SNA en ROUTOPTS, también debe especificarse la NCFAPPL en la palabra clave OPCOPTS o de lo contrario el controlador emite un mensaje de error y termina la inicialización. Nota: No existe comprobación cruzada automática entre las definiciones de recursos de dominio cruzado de VTAM y los nombres de unidades lógicas especificados en la palabra clave SNA. Debe asegurarse de que las unidades lógicas puedan comunicarse a través los dominios VTAM si es necesario. TCPIP(destino,...,destino) Define las direcciones de red para comprobadores de seguimiento conectado por TCP/IP que pueden comunicarse con el controlador a efectos de seguimiento de trabajos. El destino se compone de un nombre de destino, un nombre de host o dirección IP y opcionalmente un número de puerto. Definir este parámetro requiere la definición de un segmento OMVS para el identificador de usuario del controlador. Las siguientes reglas son aplicables a los subvalores de destino: v El nombre de destino puede tener hasta 8 caracteres alfanuméricos. Junto con el nombre de host o la dirección IP, se usa para direccionar el trabajo enviado. Este subvalor es necesario. v El nombre de host o la dirección IP pueden tener hasta 52 caracteres alfanuméricos. Puede contener un nombre de host o dirección IP en formato IPV4 o IPV6. Este valor debe escribirse entre comillas. Este subvalor es necesario. v El número de puerto puede tener hasta 5 caracteres numéricos. Los valores válidos están comprendidos entre 0 y 65535. Este subvalor es opcional. El valor predeterminado es 0, lo cual significa que se acepta cualquier número de puerto. v Los nombres de destino y el nombre de host o la dirección IP deben estar estar separados por dos puntos. v Los valores requeridos y el número de puerto deben estar separados por una barra oblicua. USER(destino,...,destino) Esta palabra clave identifica destinos definidos por el usuario. Cada nombre de destino es un nombre alfanumérico compuesto de 1-8 caracteres, donde el primer carácter es alfabético. El protocolo de comunicación y el manejo del control de sesión se definen en la salida de iniciación de operación, EQQUX009. La salida está situada en el controlador de Tivoli Workload 158 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste ROUTOPTS Scheduler for z/OS. Se llama cuando las operaciones están listas para ser iniciadas en una estación de trabajo que especifica un destino definido en la palabra clave USER. Esta palabra clave también define los nombres de destinos especificados en la estación de trabajo de automatización para identificar el identificador de dominio NetView de destino donde deben ejecutarse los mandatos de System Automation. XCF(destino,...,destino) Esta palabra clave identifica todos los destinos XCF. Cada destino es el nombre de miembro XCF de un comprobador de seguimiento. Los miembros XCF que aparecen deben ser parte del mismo grupo XCF que el controlador. Si la palabra clave XCF está presente en ROUTOPTS, también debe estar presente la sentencia XCFOPTS. Si no se encuentra la sentencia XCFOPTS, el controlador emite un mensaje de error y termina la inicialización. Si un destino que aparece en la palabra clave XCF no es un miembro activo del mismo grupo XCF que el controlador, no se transmite trabajo a este destino. Ejemplos ROUTOPTS XCF(SYS1,SYS2) 1 SNA(SYSA) 2 TCPIP(DEST1:’1.111.111.111’/4444) 3 DASD(SYSB) 4 USER(OS2LAN) 5 HTTP(ZCENT1:’192.27.144.12’/44112, ZCENT2:’192.14.55.231’/61424) HTTPS(REMZ1:’192.27.144.13’/44113,/Z) 6 7 En este ejemplo de una sentencia ROUTOPTS, el controlador está conectado a cuatro comprobador de seguimiento ejecutados en z/OS. El trabajo también se somete a un sistema OS/2 mediante la salida de iniciación de operación: | | | 1 SYS1 y SYS2 están conectadas mediante enlaces de comunicación XCF y están definidas en la palabra clave XCF. 2 La comunicación con SYSA se realiza mediante un enlace VTAM definido en la palabra clave SNA. 3 DEST1 identifica un enlace TCP/IP con un comprobador de seguimiento y sus detalles se definen en la palabra clave TCPIP. 4 El controlador envía el trabajo a un comprobador de seguimiento usando un conjunto de datos de envío/liberación. El ddname del conjunto de datos de envío/liberación del procedimiento JCL del controlador es SYSB, tal y como se especifica en la palabra clave DASD. 5 El controlador llama a la salida de iniciación de operación, EQQUX009, cuando las operaciones están listas para ser iniciadas en estaciones de trabajo que especifican el destino OS2LAN. 6 ZCENT1 y ZCENT2 especifica los enlaces en dos estaciones de trabajo Tivoli Workload Scheduler for z/OS agent. ZCENT1 y ZCENT2 se deben especificar también como nombres de destino en las definiciones de estaciones de trabajo del Tivoli Workload Scheduler for z/OS agent. 7 REMZ1 especifica el enlace a la estación de trabajo de motor remoto z/OS. REMZ1 también debe especificarse como nombre de destino en la definición de la estación de trabajo del motor remoto. Capítulo 1. Definición de sentencias de inicialización 159 ROUTOPTS | | | | | | Modificación de los destinos HTTP | | | donde procname es el nombre de procedimiento JCL de Tivoli Workload Scheduler for z/OS. Para obtener información detallada sobre el mandato MODIFY, consulte Tivoli Workload Scheduler for z/OS: Managing the Workload. | | | | | Puede añadir un máximo de 100 destinos sin tener que reiniciar el controlador. El mandato MODIFY gestiona hasta un total de 100 nuevos destinos, independientemente de si se añaden de una vez o en diversos momentos. Después de 100 destinos añadidos, debe detener y reiniciar el controlador para que el mandato MODIFY gestione otros 100 destinos nuevos. | | Nota: Suprimir un destino HTTP o HTTPS no aumenta el número máximo de adiciones permitidas. | | | Puede modificar o suprimir un número ilimitado de destinos HTTP o HTTPS. Sin embargo, si modifica el destino nombre esta operación se considera que añade un nuevo destino. | | | Cuando se define el primer destino con la sentencia ROUTOPTS, para hacer efectivo este valor se debe detener y reiniciar el controlador. No se puede ejecutar el mandato MODIFY. | | | | Para mostrar una lista de los destinos HTTP o HTTPS actualmente utilizados por el controlador, indique el mandato del operador MODIFY (la lista se almacena en MLOG): /F procname,DSPDEST | | donde procname es el nombre de procedimiento JCL de Tivoli Workload Scheduler for z/OS. | | | | Si ejecuta un mandato MODIFY para renovar los destinos o mostrar la lista de destinos en uso mientras se procesa otro mandato para renovar los destinos, se emite el mensaje de error EQQHT50W. Espere a que se complete el mandato de renovación y luego vuelva a especificar el mandato. Puede modificar, añadir o suprimir un destino HTTP o HTTPS mientras se ejecuta Tivoli Workload Scheduler for z/OS. Para hacer efectivos de inmediato los cambios, sin detener y reiniciar el controlador, especifique el mandato del operador MODIFY siguiente: /F procname,RFRDEST 160 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste SERVOPTS SERVOPTS Propósito La sentencia SERVOPTS es para un servidor que maneja transacciones dirigidas al nombre de subsistema del controlador en el mismo sistema z/OS que el servidor. Formato SERVOPTS NO YES ARM( ) IBM – 037 página de códigos del sistema principal CODEPAGE( ) DBOPT nombre de miembro DBOPTPRM( ) nombre de host local nombrehost dirección IP JSCHOSTNAME( ) 425 valor PORTNUMBER( , ) PROTOCOL( APPC E2E TCP SUBSYS( ) Nombre de subsistema de controlador ) , SCHEDULER( Nombre de planificador ) | TASKUSR( YES NO ) TPLGYPRM( TPLGPARM nombre de miembro ) USERMAP( miembro de la biblioteca de parámetros ) Parámetros Esta sección describe los parámetros aplicables a todos los tipos de conexiones. Los parámetros específicos a un tipo de conexión se describen por separado en las siguientes secciones. ARM (YES|NO) El gestor de reinicio automático (ARM) de z/OS puede reducir el impacto de un código de error inesperado en Tivoli Workload Scheduler for z/OS porque z/OS puede reiniciarlo automáticamente sin que intervenga el operador. Especifique YES si debe activarse el reinicio automático del componente anómalo de Tivoli Workload Scheduler for z/OS. La recuperación ARM del componente anómalo de Tivoli Workload Scheduler for z/OS es posible en la misma imagen (reinicio). Esta característica permite la recuperación del comprobador de seguimiento y un reinicio rápido del controlador y el servidor. Además, el reinicio no reduce el número de controladores en reposo cuando hay una anomalía en el controlador. Se puede personalizar el número de reinicios y el período de un reinicio para cada componente de Tivoli Workload Scheduler for z/OS en la política ARM de z/OS. Capítulo 1. Definición de sentencias de inicialización 161 SERVOPTS | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CODEPAGE (página de códigos del sistema principal|IBM–037) El nombre de la página de código de host. Puede proporcionar el valor IBM–nnn, donde nnn es la página de códigos EBCDIC. El valor predeterminado, IBM–037, define la página de códigos EBCDIC para inglés americano, portugués y francés de Canadá. Si especifica una página de códigos distinta del valor predeterminado, se ha implementado una comprobación que utiliza la página de códigos predeterminada si los cuatro primeros caracteres de la página de códigos especificada son distintos de "IBM-". A continuación se muestra una lista de las páginas de códigos EBCDIC: IBM–939 Japón, extendido IBM–937 Taiwán IBM–935 China IBM–933 Corea IBM–975 Grecia IBM–971 Islandia IBM–970 Latín 2 IBM–838 Tai IBM–500 Internacional IBM–424 Israel IBM–297 Francia IBM–285 Reino Unido IBM–284 España - América latina IBM–280 Italia IBM–278 Suecia - Finlandia IBM–277 Dinamarca - Noruega IBM–274 Bélgica IBM–273 Alemania IBM–1388 China IBM–1122 Estonia IBM–1112 Báltico IBM–1047 Sistemas abiertos IBM–1026 Latín 5 (Turquía) IBM–1025 Cirílico | | | | | | | | | | | | A continuación se muestra una lista de las páginas de códigos EBCDIC que aceptan EURO: IBM–1140 Finlandia, Suecia IBM–1141 Austria, Alemania IBM–1142 Dinamarca, Noruega IBM–1143 EE.UU. IBM–1144 Italia IBM–1145 España , América latina IBM–1146 Reino Unido IBM–1147 Francia IBM–1148 Bélgica, Suiza IBM–1149 Islandia DBOPTPRM(nombre de miembro|DBOPT) Indica el miembro de la PARMLIB que contiene los parámetros para conectarse a la base de datos y gestionar el proceso de archivado de datos hostóricos. JSCHOSTNAME (JSChostname|dirección IP| nombre de host local) Especifica el nombre de host o la dirección IP usados por una aplicación remota para conectarse al servidor cuando PROTOCOL=TCP. El valor predeterminado es el nombre de host devuelto por el sistema operativo. 162 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste SERVOPTS Puede definir una dirección IP virtual para cada servidor del controlador activo y los controladores en reposo. Si usa una dirección IP virtual dinámica en un entorno SYSPLEX, cuando el controlador activo falla y el controlador en reposo se hace cargo de la comunicación, la aplicación remota cambia automáticamente la comunicación al servidor del controlador en reposo. Si especifica la sentencia TCPOPTS para el servidor, el parámetro HOSTNAME altera temporalmente el parámetro JSCHOSTNAME en la sentencia SERVOPTS. También se aplica si el parámetro HOSTNAME no está definido explícitamente: en este caso, el valor predeterminado anula temporalmente cualquier valor distinto especificado en la sentencia SERVOPTS. PORTNUMBER (valor|425) El número de puerto usado por el servidor cuando PROTOCOL=TCP. Los valores válidos están comprendidos entre 0 y 65535. El valor predeterminado es 425. Este número de puerto lo usa el servidor para conectarse a la aplicación remota. Seleccione diferentes valores para este parámetro y el especificado en la sentencia TOPOLOGY. Si especifica la sentencia TCPOPTS para el servidor, el parámetro SRVPORTNUMBER altera temporalmente el parámetro PORTNUMBER en la sentencia SERVOPTS. También se aplica si el parámetro SRVPORTNUMBER no está definido explícitamente: en este caso, el valor predeterminado anula temporalmente cualquier valor distinto especificado en la sentencia SERVOPTS. PROTOCOL (APPC,E2E,TCP) Identifica los tipos de comunicación usada por el servidor. Puede especificar cualquier combinación de los siguientes valores separados por una coma: APPC Para comunicación con diálogo ISPF y PIF mediante el protocolo APPC. TCP Para comunicación con diálogo ISPF, PIF, Job Scheduling Console y Tivoli Dynamic Workload Console mediante el protocolo TCP/IP. E2E Para comunicación con un entorno distribuido mediante el protocolo TCP/IP. Por ejemplo, PROTOCOL(E2E,TCP) activa toda la comunicación con el servidor mediante el protocolo TCP/IP. Si no especifica esta palabra clave, se usa APPC como valor predeterminado. Nota: Aunque puede configurar una tarea de servidor para manejar varios protocolos, por ejemplo PROTOCOL(E2E,APPC,TCP), considere tener varias tareas de servidor, cada una de ellas con una función PROTOCOL. Si usa tareas de servidor separadas, puede: v maximizar el tiempo que el servidor está en ejecución; de hecho no necesita apagar el servidor para configurar otro valor PROTOCOL. v minimizar la aparición de problemas de manejo de almacenamiento. SCHEDULER (nombre de planificador) Identifica el nombre del servidor como un planificador APPC. Este parámetro sólo se usa si se establece PROTOCOL como APPC. Si omite este parámetro, se usa el nombre de tarea iniciada como nombre de planificador. SUBSYS (nombre de subsistema de controlador) Identifica el controlador para el que este servidor ha sido iniciado. USERMAP (miembro de la biblioteca de parámetros) Define un miembro en el archivo identificado por la sentencia DD EQQPARM en el trabajo de inicio del servidor. Este miembro contiene todas las Capítulo 1. Definición de sentencias de inicialización 163 SERVOPTS asociaciones entre un usuario de conector z/OS y un identificador de usuario de RACF. Si existe el usuario USERMAP, se ignora la clase de seguridad TMEADMIN. El miembro del conjunto de datos de parámetros de inicialización debe contener, por ejemplo: USER ’SCOT@HOST’ RACFUSER(SCOT) RACFGROUP(TIVOLI) USER ’PAOLO@HOST1’ RACFUSER(FALSI) RACFGROUP(TIVOLI) USER ’MOSSOTT@HOST’ RACFUSER(FMOSSOTT) RACFGROUP(TIVOLI) Parámetros USER "Tivoli_Administrator_ID" El administrador de Tivoli que intenta iniciar sesión en Tivoli Workload Scheduler for z/OS usando la interfaz gráfica de usuario Java (campo obligatorio). El formato identificador_usuario recibido desde Job Scheduling Console es Administrador-en-TMR_región. Para obtener más información sobre Administrador-en-TMR_región, consulte “ID de usuario implicados en Dynamic Workload Console” en la página 208, en el Capítulo 3. RACFUSER(RACF_user_ID) El usuario de RACF relacionado con el administrador de Tivoli (especificado en la palabra clave USER). Este campo es obligatorio y puede tener hasta 8 caracteres de longitud (consulte las definiciones de usuario de RACF). RACFGROUP(RACF_group) El grupo RACF relacionado con el usuario de RACF. Este campo es opcional y puede tener hasta 8 caracteres de longitud (consulte las definiciones de grupo RACF). Se usa para establecer un grupo diferente del predeterminado asociado con el identificador_usuario_RACF especificado del RACFUSER. | | | TASKUSR(NO|YES) Especifica si una tarea iniciada se va a ejecutar con el ID de usuario asociado a la tarea en lugar del ID de usuario especificado con el nombre de trabajo. | | YES La tarea se ejecuta con el ID de usuario asociado al nombre de la tarea iniciada. Es el valor predeterminado. | NO La tarea se ejecuta con el ID de usuario asociado al nombre del trabajo. TPLGYPRM(nombre de miembro|TPLGPARM) Especifique este parámetro para activar la característica de planificación global con capacidades de tolerancia a errores cuando establece PROTOCOL como E2E. El nombre de miembro especificado es un miembro de la PARMLIB en la que las opciones globales con tolerancia a errores son definidas por la sentencia TOPOLOGY. Ejemplos SERVOPTS SUBSYS(OPCA) SCHEDULER(OSCA) 1 2 En este ejemplo de una sentencia SERVOPTS: 164 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste SERVOPTS 1 El servidor maneja transacciones APPC dirigidas al OPCA del controlador en el mismo sistema z/OS que el servidor. 2 El nombre del servidor como un planificador de APPC. Capítulo 1. Definición de sentencias de inicialización 165 TCPOPTS TCPOPTS Propósito La sentencia TCPOPTS opcional define atributos locales para un componente de producto que actúa como socio en una comunicación TCP/IP. Decida si quiere especificarla considerando cada componente según un modelo de cliente-servidor: Rol del cliente Es el rol de: v La tarea iniciada del comprobador de seguimiento, en una comunicación de comprobador de seguimiento a controlador. v La tarea iniciada del almacén de datos, en una comunicación de almacén de datos a controlador. v La interfaz remota (diálogo ISPF o programa PIF), en una comunicación interfaz a servidor remota. Rol del servidor Es el rol de: v La tarea iniciada del controlador, en una comunicación de comprobador de seguimiento a controlador o una comunicación de almacén de datos a controlador. v La tarea iniciada del servidor, en una comunicación de interfaz a servidor remota. La mayor parte de los parámetros TCPOPTS, dependiendo de qué componente los especifica, pueden afectar a las distintas áreas funcionales: reinicio de conexión automática después de una sustitución de controlador en reposo (aprovechando VIPA - Virtual Internet Protocol Addressing dinámico), gestión de cortafuegos, Secure Sockets Layer (SSL), gestión de tiempo de espera de conexión. La siguiente tabla agrupa los parámetros TCPOPTS por área funcional y componente interesado: Rol del cliente Rol del servidor Reinicio automático mediante VIPA dinámico HOSTNAME válido para tarea iniciada de controlador o servidor. Gestión de cortafuegos HOSTNAME válido para tarea iniciada de controlador o servidor. TRKPORTNUMBER válido para tarea iniciada de controlador. DSTPORTNUMBER válido para tarea iniciada por controlador. SRVPORTNUMBER válido para tarea iniciada de servidor. Tiempo de espera de conexión 166 CONNTIMEOUT IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste TCPOPTS SSL Rol del cliente Rol del servidor SSLLEVEL SSLLEVEL SSLKEYSTORE SSLKEYSTORE SSLKEYSTOREPSW SSLKEYSTOREPSW SSLAUTHMODE SSLAUTHMODE SSLAUTHSTRING SSLAUTHSTRING Especifique los mismos valores para todos los socios de comunicación. Especifique los mismos valores para todos los socios de comunicación. TCPIPJOBNAME válido para la tarea iniciada del controlador Interfaz de Tivoli Enterprise Portal Puede definir la sentencia TCPOPTS en el archivo de parámetros identificado por las siguientes sentencias de controlador de dispositivo: v EQQPARM, en el procedimiento del controlador. v EQQPARM, en el procedimiento del comprobador de seguimiento. v EQQPARM, en el procedimiento del almacén de datos. v EQQPARM, en el procedimiento del servidor. v EQQYPARM, en el procedimiento de inicio de sesión de TSO del usuario de diálogo. v EQQYPARM, en el JCL usado para ejecutar la aplicación PIF. Formato TCPOPTS CONNTIMEOUT( 60 Intervalo de tiempo de espera de TCPIP ) DSTPORTNUMBER( NúmeroPuerto Puerto TCPIP SRVPORTNUMBER( 425 Puerto TCPIP SSLAUTHSTRING( tws serie de SSL ) HOSTNAME( nombre de host local nombrehost dirección IP ) ) SSLAUTHMODE( CAONLY STRING ) ) SSLKEYSTORE( Nombre de archivo de base de datos de almacén de claves de SSL ) SSLKEYSTOREPSW( Nombre de archivo de contraseña del almacén de claves de SSL ) Capítulo 1. Definición de sentencias de inicialización 167 TCPOPTS SSLLEVEL( OFF FORCE ) TCPIPJOBNAME( TCPIP Tarea iniciada TCPIP ) TRKPORTNUMBER( NúmeroPuerto Puerto TCPIP ) Parámetros CONNTIMEOUT(intervalo de tiempo de espera de TCPIP|60) Define cuántos segundos intenta esperar una conexión TCP/IP antes de que se produzca un tiempo de espera. Se expresa en segundos. Los valores válidos están comprendidos entre 1 y 10000. El valor predeterminado es 60. DSTPORTNUMBER(puerto TCPIP|NúmeroPuerto) El número de puerto TCP/IP local usado por las subtareas de comunicación TCP/IP del controlador y del almacén de datos. Los valores válidos están comprendidos entre 0 y 65535. El valor NúmeroPuerto predeterminado puede ser uno de los siguientes: 423 Se aplica sólo al controlador. 0 Se aplica al almacén de datos, lo cual significa que el proceso devuelve el valor real. HOSTNAME(nombre de host|dirección IP| nombre de host local) El nombre de host o la dirección IP usados por el componente del planificador. El valor predeterminado es la dirección IP devuelta por TCP/IP. Puede tener hasta 52 caracteres alfanuméricos y especifica un nombre de host o una dirección IP en formato IPV4 o IPV6. Este valor debe escribirse entre comillas. Si especifica este parámetro para el servidor anula temporalmente la JSCHOSTNAME especificada en la sentencia SERVOPTS, si la hay. Omitir este parámetro puede afectar al tiempo que tarda el proceso de inicialización del servidor. De hecho TCP/IP debe liberar recursos usados por conexiones abiertas anteriormente: antes de hacerlo, espera el tiempo especificado en el perfil TCP/IP, mediante el parámetro FINWait2time de la sentencia TCPCONFIG. Cuando se alcanza este límite de tiempo, el sistema espera otros 75 segundos antes de eliminar la conexión. El valor predeterminado es 600 segundos, pero puede especificar un valor inferior. Para obtener detalles sobre la sentencia TCPCONFIG consulte z/OS Communication Server IP Configuration Reference. SRVPORTNUMBER(puerto TCPIP|425) El número de puerto TCP/IP local usado por el servidor. Anula temporalmente la PORTNUMBER especificada en la sentencia SERVOPTS. Los valores válidos están comprendidos entre 0 y 65535. El número de puerto predeterminado es 425. En una comunicación con interfaz de servidor-a-remota, este parámetro se aplica sólo al servidor, mientras que la interfaz remota lo ignora: de hecho siempre usa un número de puerto asignado por TCP/IP como puerto local. SSLAUTHMODE(STRING|CAONLY) El tipo de autenticación SSL. Especifique uno de los siguientes valores: CAONLY El planificador comprueba la validez del certificado verificando que una entidad emisora de certificados haya emitido el certificado de interlocutor. No se comprueba la información contenida en el certificado. Éste es el valor predeterminado. 168 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste TCPOPTS STRING El planificador comprueba la validez del certificado tal y como se describe en la opción CAONLY. También verifica que el nombre común (CN) del Asunto del certificado coincide con la serie especificada en el parámetro SSLAUTHSTRING. Para evitar errores de comunicación, especifique el mismo valor SSLLEVEL para las tareas iniciadas del planificador que tengan que comunicarse entre sí. SSLAUTHSTRING(serie SSL|tws) Define una serie usada para verificar la validez del certificado cuando se establece SSLAUTHMODE como STRING. La serie puede contener hasta 64 caracteres. El valor predeterminado es tws. SSLKEYSTORE(Nombre de archivo de base de datos de almacén de claves de SSL) Identifica la base de datos que contiene las claves y los certificados. Está formada por un nombre de directorio y nombre de archivo con SSL, con formato SSLworkdir/TWS.kbd. Es sensible a mayúsculas y minúsculas. Este campo es necesario si se establece el parámetro SSLLEVEL como FORCE. SSLKEYSTOREPSW(Nombre de archivo de contraseña del almacén de claves de SSL) Identifica el archivo que contiene la contraseña de clave. Está formada por un nombre de directorio y nombre de archivo SSL, con formato SSLworkdir/TWS.sth. Es sensible a mayúsculas y minúsculas. Este campo es necesario si se establece el parámetro SSLLEVEL como FORCE. SSLLEVEL(FORCE|OFF) El tipo de autenticación SSL. Especifique uno de los siguientes valores: OFF El componente del planificador no da soporte a la autenticación SSL para sus componentes. Este es el valor predeterminado. FORCE El planificador utiliza la autenticación SSL para todas las conexiones. Rechaza cualquier conexión entrante si no es SSL. Para evitar errores de comunicación, especifique el mismo valor SSLLEVEL para las tareas iniciadas del planificador que tengan que comunicarse entre sí. TCPIPJOBNAME(tarea iniciada TCPIP|TCPIP) El nombre de la tarea iniciada TCP/IP que se está ejecutando en el sistema z/OS donde se ejecuta el componente del planificador. Establezca este parámetro cuando tenga varias pilas TCP/IP o una tarea iniciada TCP/IP con un nombre distinto de TCPIP. TRKPORTNUMBER(puerto TCPIP|NúmeroPuerto) El número de puerto TCP/IP local usado por las subtareas de comunicación TCP/IP del controlador y del comprobador de seguimiento. Los valores válidos están comprendidos entre 0 y 65535. El valor NúmeroPuerto predeterminado puede ser uno de los siguientes: 424 Se aplica sólo al controlador. 0 Se aplica al comprobador de seguimiento, lo cual significa que el proceso devuelve el valor real. Capítulo 1. Definición de sentencias de inicialización 169 TCPOPTS Ejemplos TCPOPTS TCPIPJOBNAME(’TCPIP’) HOSTNAME(’1.111.111.111’) TRKPORTNUMBER(4444) 1 2 3 En este ejemplo de una sentencia TCPOPTS: 170 1 El nombre de la tarea iniciada TCP/IP se establece con el valor predeterminado. 2 La dirección IP 1.111.111.111 identifica la tarea iniciada del planificador en la red TCP/IP. 3 4444 es el número de puerto local en una comunicación de comprobador de seguimiento a controlador. IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste TOPOLOGY TOPOLOGY Propósito La sentencia TOPOLOGY define las contraseñas para los usuarios que necesitan planificar trabajos para ser ejecutados en estaciones de trabajo Windows. Omítala si su entorno de planificación no incluye estas estaciones de trabajo. Para obtener una descripción detallada de esta sentencia, consulte el manual Tivoli Workload Scheduler for z/OS: Planificación global con capacidades de tolerancia a errores. Capítulo 1. Definición de sentencias de inicialización 171 TRGOPT TRGOPT Propósito Especifique esta sentencia para dar soporte a la automatización de carga de trabajo controlada por sucesos. La usa el programa Java que crea archivos de configuración para el desencadenamiento de conjuntos de datos. Formato TRGOPT CODEPAGE( IBM – 037 página de códigos del sistema principal ) TRACELEVEL( 0 nivel WRKDIR( directorio de trabajo ) ) Parámetros CODEPAGE (página de códigos del sistema principal|IBM–037) El nombre de la página de código de host. Puede proporcionar el valor IBM–nnn, donde nnn es la página de códigos EBCDIC. El valor predeterminado, IBM–037, define la página de códigos EBCDIC para inglés americano, portugués y francés de Canadá. A continuación se muestra una lista de las páginas de códigos EBCDIC: IBM–939 Japón, extendido IBM–937 Taiwán IBM–935 China IBM–933 Corea IBM–975 Grecia IBM–971 Islandia IBM–970 Latín 2 IBM–838 Tai IBM–500 Internacional IBM–424 Israel IBM–297 Francia IBM–285 Reino Unido IBM–284 España - América latina IBM–280 Italia IBM–278 Suecia - Finlandia IBM–277 Dinamarca - Noruega IBM–274 Bélgica IBM–273 Alemania IBM–1388 China IBM–1122 Estonia IBM–1112 Báltico IBM–1047 Sistemas abiertos IBM–1026 Latín 5 (Turquía) IBM–1025 Cirílico A continuación se muestra una lista de las páginas de códigos EBCDIC que aceptan EURO: IBM–1140 Finlandia, Suecia IBM–1141 Austria, Alemania 172 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste TRGOPT IBM–1142 IBM–1143 IBM–1144 IBM–1145 IBM–1146 IBM–1147 IBM–1148 Dinamarca, Noruega EE.UU. Italia España , América latina Reino Unido Francia Bélgica, Suiza TRACELEVEL (nivel|0) Nivel de rastreo para registro cronológico y rastreo interno. Los valores posibles son los siguientes: 0 Para recibir sólo mensajes de error. 1 Para recibir mensajes de error y de aviso. 2 Para recibir mensajes de error, de aviso e informativos. 3 Indica el nivel ajustado para recibir los mensajes más importantes con el volumen más bajo. 4 Indica el nivel algo más ajustado para activar los rastreos de entrada y salida. 5 Indica el nivel más ajustado para recibir el rastreo más detallado. El valor predeterminado es 0. Encontrará la salida del rastreo en el mismo directorio de trabajo que se especifica en el parámetro WRKDIR. WRKDIR (directorio de trabajo) La vía de acceso completa del directorio de trabajo para el proceso de compilación de de los archivos de configuración. Cada subsistema debe tener su propio directorio de trabajo. Puede usar el mismo directorio de trabajo usado en la planificación global con capacidades de tolerancia a errores. Este parámetro es necesario y no tiene un valor predeterminado. Ejecute EQQPCS08 para personalizar el contenido del directorio de trabajo. Este parámetro es necesario y no tiene un valor predeterminado. Capítulo 1. Definición de sentencias de inicialización 173 TRROPTS TRROPTS Propósito La sentencia TRROPTS define las opciones de direccionamiento desde el comprobador de seguimiento de un z/OS que esté conectado al controlador mediante DASD, SNA (VTAM), XCF o TCP/IP. Incluya TRROPTS en las sentencias de cada comprobador de seguimiento de z/OS de su sistema en su configuración de Tivoli Workload Scheduler for z/OS, excepto donde el comprobador de seguimiento y el controlador se inicien en el mismo espacio de direcciones. Use TRROPTS donde se especifique OPCOPTS OPCHOST(NO). TRROPTS se define en el miembro de la biblioteca EQQPARM tal y como se especifica con el parámetro PARM de la sentencia JCL EXEC. Formato TRROPTS HOSTCON( DASD SNA TCP XCF ) , SNAHOST( Nombre de unidad lógica VTAM ) TCPHOSTNAME( nombrehost dirección IP ) TCPPORTNUMBER( 424 Puerto TCPIP ) Parámetros HOSTCON(DASD|SNA|TCP|XCF) La palabra clave HOSTCON identifica la conexión usada al transmitir sucesos al controlador. Si especifica HOSTCON(DASD), no podrá especificar EWSEQNO en la sentencia EWTROPTS. Si especifica HOSTCON(SNA), la palabra clave SNAHOST debe contener el nombre de unidad lógica de NCF del controlador. Este comprobador de seguimiento debe tener también la palabra clave NCFAPPL especificada en la sentencia OPCOPTS. Si especifica HOSTCON(XCF), también debe estar presente la sentencia XCFOPTS. Si especifica HOSTCON(TCP), establezca también TCPHOSTNAME para identificar el controlador remoto. SNAHOST(Nombre de unidad lógica VTAM,...,Nombre de unidad lógica VTAM) La palabra clave SNAHOST es necesaria para los comprobador de seguimientoes conectados al controlador mediante aun enlace SNA. Esta palabra clave define el nombre de unidad lógica VTAM del controlador y cualquier controlador en reposo. En una configuración en reposo, puede especificar varios nombres de unidad es lógicas. Durante la inicialización, el comprobador de seguimiento inicia la sesión en el nombre de unidad lógica 174 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste TRROPTS donde SNAHOST se activa por primera vez. Es decir, el comprobador de seguimiento intenta comunicarse con la primera tarea iniciada de IBM Tivoli Workload Scheduler for z/OS identificada como el controlador. Si especifica la palabra clave SNAHOST, la palabra clave HOSTCON debe ser SNA. TCPHOSTNAME (nombrehost|dirección IP) Especifica el nombre host o la dirección IP del controlador remoto. Los valores válidos son nombres completos de hasta 52 caracteres.Este parámetro es obligatorio. TCPPORTNUMBER (valor|424) Define el número de puerto TCP/IP usado para comunicarse con el controlador remoto. Los valores válidos están comprendidos entre 0 y 65535. Si no se especifica, se usa el valor predeterminado 424. Ejemplos TRROPTS HOSTCON(SNA) SNAHOST(NCFAPPL1) 1 2 En este ejemplo de una sentencia TRROPTS: 1 El comprobador de seguimiento se conecta al controlador mediante un enlace VTAM. 2 El nombre del nombre de unidad lógica NCF usado por el controlador es NCFAPPL1. Capítulo 1. Definición de sentencias de inicialización 175 USRREC USRREC Propósito Esta sentencia define las contraseñas para los usuarios que necesitan planificar trabajos para ser ejecutados en estaciones de trabajo Windows. Omítala si si entorno de planificación no incluye estas estaciones de trabajo o si decide definir el identificador de usuario y la contraseña de Windows localmente en las estaciones de trabajo (en el último caso, debe establecer LOCALPSW(YES) en la sentencia TOPOLOGY). USRREC se define en el miembro de la biblioteca EQQPARM tal y como se especifica con la palabra clave USRMEM de la sentencia siguiente: Planificación global con capacidades de tolerancia a errores TOPOLOGY. Esta sentencia se lee en la fase de renovación, nueva planificación o ampliación de Symphony de planificación diaria. Para obtener una descripción detallada de la sentencia TOPOLOGY, consulte el manual Tivoli Workload Scheduler for z/OS: Planificación global con capacidades de tolerancia a errores. Planificación global con capacidades de z-centric HTTPOPTS. Esta sentencia se lee en el inicio del controlador. Para obtener una descripción detallada de la sentencia HTTPOPTS, consulte el manual Tivoli Workload Scheduler for z/OS: Planificación global con capacidades de z-centric. 176 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste XCFOPTS XCFOPTS Propósito La sentencia XCFOPTS define las opciones de tiempo de ejecución para sistemas Tivoli Workload Scheduler for z/OS que usan servicios del recurso de acoplamiento entre sistemas (XCF). Especifique esta sentencia para un comprobador de seguimiento, controlador o controlador en reposo que use XCF para comunicarse. XCFOPTS se define en el miembro de la biblioteca EQQPARM tal y como se especifica con el parámetro PARM de la sentencia JCL EXEC. Formato XCFOPTS GROUP( Nombre de grupo XCF ) MEMBER( Nombre de miembro XCF ) , TAKEOVER( HOSTFAIL SYSFAIL ) Parámetros GROUP(Nombre de grupo XCF) El nombre del grupo XCF al que el sistema de Tivoli Workload Scheduler for z/OS debe unirse.Es un nombre alfanumérico compuesto por 1 a 8 caracteres donde el primer carácter es alfabético. El nombre de este grupo XCF debe ser distinto del definido en los grupos DSTOPS y FLOPTS. MEMBER(Nombre de miembro XCF) El nombre de miembro XCF que identifica el sistema Tivoli Workload Scheduler for z/OS. Es un nombre alfanumérico compuesto por 1 a 8 caracteres donde el primer carácter es alfabético. El nombre de miembro debe ser único dentro del grupo. Si un sistema Tivoli Workload Scheduler for z/OS intenta unirse a un grupo con el mismo nombre de un grupo existente, se emite un mensaje de error y Tivoli Workload Scheduler for z/OS deja de funcionar. TAKEOVER(HOSTFAIL,SYSFAIL) La palabra clave TAKEOVER se aplica a un sistema Tivoli Workload Scheduler for z/OS donde se especifica OPCHOST(STANDBY) en la sentencia OPCOPTS. Define las situaciones en las que el sistema en reposo toma el control automáticamente del sistema Tivoli Workload Scheduler for z/OS si hay una anomalía en el host. Si no ha especificado TAKEOVER, Tivoli Workload Scheduler for z/OS envía un mensaje WTO a la consola del operador pidiendo al operador que inicia manualmente las acciones de sustitución. Puede especificar una o ambas condiciones de sustitución. HOSTFAIL La sustitución automática se produce cuando hay una anomalía en el controlador. SYSFAIL La sustitución automática se produce cuando hay una Capítulo 1. Definición de sentencias de inicialización 177 XCFOPTS anomalía en el sistema donde se está ejecutando el controlador del Tivoli Workload Scheduler for z/OS. Ejemplos XCFOPTS MEMBER(GRP1STBY) GROUP(XCFGRP1) TAKEOVER(HOSTFAIL,SYSFAIL) 1 2 3 En este ejemplo de una sentencia XCFOPTS: 178 1 Un controlador en reposo tiene un nombre de miembro de GRP1STBY. 2 GRP1STBY es un miembro del grupo XCF XCFGRP1. 3 El controlador en reposo intenta automáticamente sustituir las funciones del controlador si hay una anomalía en el controlador o si hay una anomalía en el sistema z/OS donde se está ejecutando el controlador. IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Capítulo 2. Identificación de sentencias-parámetros de inicialización relacionados Este capítulo describe las sentencias y parámetros de inicialización relacionados. Puede utilizar esta información para identificar los parámetros a tener en cuenta al implementar funciones particulares y para evaluar el efecto en otros procesos que pueda tener una función. Se describen estas funciones: v Configuración v Seguridad v Generación de información de auditoría (datos de registro JT) v Determinación del éxito o fracaso de un trabajo v Recuperación – Reinicio y limpieza – Recuperación automática de trabajos – Reinicio de la carga de trabajo v Rendimiento v Generación de informes v Supervisión de RODM v Proceso de salida v Planificación global con capacidades de tolerancia a errores v Integración de WLM v Supervisión externa La Tabla 5 muestra las sentencias descritas en este capítulo y las funciones a las que hacen referencia. El Capítulo 1, “Definición de sentencias de inicialización”, en la página 5 describe todas las sentencias detalladamente. Tabla 5. Sentencias de inicialización y funciones relacionadas Sentencia información sobre las funciones relacionadas ALERTS “Rendimiento” en la página 186 y “Supervisión externa” en la página 193 AROPTS “Seguridad” en la página 181 y “Recuperación” en la página 183 AUDIT “Seguridad” en la página 181, “Generación de información de auditoría (datos de registro JT)” en la página 182, y “Rendimiento” en la página 186 AUTHDEF “Seguridad” en la página 181, “Generación de información de auditoría (datos de registro JT)” en la página 182, y “Rendimiento” en la página 186 BATCHOPT “Generación de información de auditoría (datos de registro JT)” en la página 182, “Generación de informes” en la página 187 y “Recuperación” en la página 183 CPUREC “Planificación global con capacidades de tolerancia a errores” en la página 189 ERDROPTS “Configuración” en la página 180 EWTROPTS “Configuración” en la página 180, “Generación de información de auditoría (datos de registro JT)” en la página 182, “Determinación del éxito o fracaso de un trabajo” en la página 182, “Recuperación” en la página 183 y “Rendimiento” en la página 186 FLOPTS “Recuperación” en la página 183, “Recuperación de registros de trabajo” en la página 185 JCCOPTS “Determinación del éxito o fracaso de un trabajo” en la página 182 JOBREC “Planificación global con capacidades de tolerancia a errores” en la página 189 JTOPTS “Generación de información de auditoría (datos de registro JT)” en la página 182, “Determinación del éxito o fracaso de un trabajo” en la página 182, “Recuperación” en la página 183, “Rendimiento” en la página 186 y “Generación de informes” en la página 187 © Copyright IBM Corp. 1991, 2011 179 Tabla 5. Sentencias de inicialización y funciones relacionadas (continuación) Sentencia información sobre las funciones relacionadas MONOPTS “Supervisión externa” en la página 193 MONPOL “Supervisión externa” en la página 193 NOERROR “Determinación del éxito o fracaso de un trabajo” en la página 182 y “Recuperación” en la página 183 OPCOPTS “Configuración”, “Recuperación” en la página 183, “Rendimiento” en la página 186, “Supervisión de RODM” en la página 188, “Proceso de salida” en la página 188, “Integración de WLM” en la página 192 y “Supervisión externa” en la página 193 RCLOPTS “Recuperación” en la página 183 RECOVERY “Planificación global con capacidades de tolerancia a errores” en la página 189 RESOURCE “Generación de informes” en la página 187 RODMOPTS “Supervisión de RODM” en la página 188 ROUTOPTS “Configuración” en la página 180 y “Supervisión de RODM” en la página 188 SERVOPTS “Configuración” en la página 180 TOPOLOGY “Planificación global con capacidades de tolerancia a errores” en la página 189 TRROPTS “Configuración” en la página 180 USRREC “Planificación global con capacidades de tolerancia a errores” en la página 189 VARSUB “Planificación global con capacidades de tolerancia a errores” en la página 189 XCFOPTS “Configuración” en la página 180 Configuración Estas sentencias y parámetros especifican su configuración de IBM Tivoli Workload Scheduler for z/OS. Identifican los subsistemas de IBM Tivoli Workload Scheduler for z/OS y las conexiones entre ellos. Tabla 6. Parámetros relacionados con la configuración Sentencia Palabras clave Descripción OPCOPTS OPCHOST Especifica el tipo de subsistema (comprobador de seguimiento, controlador, o controlador en reposo) NCFTASK Inicia NCF para comunicación a través de VTAM EWTRTASK Inicia un grabador de sucesos para recoger sucesos desde el sistema z/OS ERDRTASK Inicia un lector de sucesos para transferir sucesos al suceso SERVERS Inicia una o más colas de servidor en el controlador TPLGYSRV Inicia la tarea de capacitación global de Tivoli Workload Scheduler EWSEQNO El grabador de sucesos también realiza la función de lector de sucesos. No es necesario un lector de sucesos distinto SUREL Especifica si el grabador de sucesos lee un conjunto de datos de envío/liberación ERSEQNO Especifica el lector de sucesos y define el ddname del conjunto de datos de sucesos de entrada RELDDNAME Especifica el conjunto de datos de envío/liberación a los que se escriben los mandatos de liberación en un entorno DASD compartido EWTROPTS ERDROPTS ROUTOPTS 180 Identifica las rutas desde el controlador hasta los destinos de comprobador de seguimiento IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Configuración Tabla 6. Parámetros relacionados con la configuración (continuación) Sentencia Palabras clave Descripción TRROPTS Identifica la ruta desde un comprobador de seguimiento hasta el controlador XCFOPTS Identifica las conexiones XCF y especifica cuándo un controlador en reposo realiza la sustitución SERVOPTS SUBSYS Identifica el controlador con el que se comunica el servidor Seguridad Estos parámetros se especifican para proteger las funciones y los datos de IBM Tivoli Workload Scheduler for z/OS, y para registrar el acceso a los datos de IBM Tivoli Workload Scheduler for z/OS. Tabla 7. Parámetros relacionados con la seguridad Sentencia Palabras clave AUTHDEF AROPTS Descripción Especifica cómo los recursos de IBM Tivoli Workload Scheduler for z/OS son definidos para RACF AUTHUSER Especifica dónde IBM Tivoli Workload Scheduler for z/OS recupera un nombre para comprobar la autoridad USERREQ Especifica si es necesario un ID de usuario válido AUDIT Especifica cuándo se registra el acceso a datos de IBM Tivoli Workload Scheduler for z/OS JTOPTS JOBCHECK Especifica si el nombre de trabajo del JCL ( lenguaje de control de trabajos) debe coincidir con el nombre de trabajo de operación USRREC USRNAM Especifica el nombre de usuario. USRPSW Especifica la contraseña de usuario. SERVOPTS USERMAP Define un miembro que contiene todas las asociaciones entre un administrador de Tivoli y un ID de usuario de RACF. TOPOLOGY LOCALPSW Especifica si el ID de usuario y la contraseña que deben usarse para las estaciones de trabajo Windows deben encontrarse localmente cuando faltan en el archivo Symphony. El entorno de seguridad se configura al instalar IBM Tivoli Workload Scheduler for z/OS. Después puede personalizar la seguridad de IBM Tivoli Workload Scheduler for z/OS especificando niveles particulares de protección. Si utiliza RACF, siga estos pasos: v Añada IBM Tivoli Workload Scheduler for z/OS a la mesa de procedimientos iniciados, ICHRIN03. Si utiliza RACF 2.1, puede en su lugar añadir IBM Tivoli Workload Scheduler for z/OS a la clase STARTED. No necesita realizar esta acción si ejecuta IBM Tivoli Workload Scheduler for z/OS como trabajo por lotes. v Añada cada nombre de subsistema IBM Tivoli Workload Scheduler for z/OS a la clase APPL. Esto determina el nivel de acceso al subsistema. v Añada una clase de recursos generales para IBM Tivoli Workload Scheduler for z/OS a la tabla de descriptor de clase. Si utiliza RACF 2.1, puede utiliza la clase de recursos generales suministrada para IBM Tivoli Workload Scheduler for z/OS, IBMOPC. v Actualice la tabla del direccionador, ICHRFR01, para especificar qué acción se realiza para la clase de recursos. Capítulo 2. Identificación de sentencias-parámetros de inicialización relacionados 181 Seguridad Después puede especificar los niveles de protección para funciones y datos particulares de IBM Tivoli Workload Scheduler for z/OS. La Installation Guide describe cómo configura el entorno de seguridad. El Capítulo 3, “Implementación de seguridad”, en la página 195 describe detalladamente cómo proteger IBM Tivoli Workload Scheduler for z/OS. Usted especifica los parámetros en las sentencias AUDIT y AUTHDEF para determinar cuándo se produce la información de AUDIT. Para obtener más información, consulte la sección “Generación de información de auditoría (datos de registro JT)”. Generación de información de auditoría (datos de registro JT) Estos parámetros determinan la cantidad de información auditable que produce IBM Tivoli Workload Scheduler for z/OS. La información se escribe al registro de seguimiento de trabajos y puede copiarse con planificación diaria al conjunto de datos del registro de seguimiento (EQQTROUT). Puede invocar AUDIT directamente desde el diálogo ISPF si está personalizado correctamente (consulte el Capítulo 4 de la Guía de instalación). Tabla 8. Parámetros relacionados con la auditoría Sentencia Palabras clave AUDIT BATCHOPT Descripción Registrar acceso a datos de IBM Tivoli Workload Scheduler for z/OS NCPTROUT Especifica si los registros de seguimiento se copian a EQQTROUT desde NCP con planificación diaria OCPTROUT Especifica si los registros de seguimiento se copian a EQQTROUT desde el CP antiguo con planificación diaria LOGID Especifica el identificador numérico colocado en todos los registros del registro de seguimiento (EQQTROUT). STEPEVENTS Especifica cuándo IBM Tivoli Workload Scheduler for z/OS crea sucesos para finalizar pasos de trabajo PRINTEVENTS Especifica si IBM Tivoli Workload Scheduler for z/OS crea sucesos para tareas de impresión (tipo 4) JTOPTS PRTCOMPLETE Especifica cuándo IBM Tivoli Workload Scheduler for z/OS establece operaciones de impresión a completar AUTHDEF LISTLOGGING Especifica cuántos datos almacena RACF para accesos a datos de IBM Tivoli Workload Scheduler for z/OS EWTROPTS Determinación del éxito o fracaso de un trabajo Estos parámetros especifican cómo IBM Tivoli Workload Scheduler for z/OS determina el siguiente estado de una operación cuando finaliza el trabajo o la tarea iniciada. Cuando el trabajo anómalo ha sido obtenido al reiniciar una operación a nivel de Paso o de Trabajo (consulte la función de Reinicio o Limpieza) y el fallo es determinado por el paso EQQCLEAN acabado en RC>=8 (y haciendo que los pasos siguientes sean desechados (FLUSH)), entonces el estado de la operación siempre da Error, alterando temporalmente cualquier lógica de comprobación de terminación implementada. Para trabajos que utilicen scripts no centralizados y ejecutados en estaciones de trabajo no tolerantes a errores, consulte la palabra clave RCCONDSUC de la sentencia JOBREC descrita en el manual Planificación global con capacidades de tolerancia a errores.. 182 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Determinación del éxito o fracaso de un trabajo Tabla 9. Parámetros relacionados con la comprobación de finalización Sentencia Palabras clave Descripción EWTROPTS RETCODE Crear sucesos con final de trabajo (3P) con código más alto o de última devolución STEPEVENTS Especifica cuándo IBM Tivoli Workload Scheduler for z/OS crea sucesos para finalizar pasos de trabajo JCCOPTS Acciones de comprobación de terminación de trabajo NOERROR LIST Códigos de error que no son errores JTOPTS NOERROR Códigos de error que no son errores HIGHRC Código de retorno más alto que no es un error ERRRES Restablecer el estado de operación a A (llegada) para estos códigos de error Estas opciones de trabajo en detalles de operación anulan temporalmente los valores de sentencia: v ERROR TRACKING v HIGHEST RETURNCODE IBM Tivoli Workload Scheduler for z/OS procesa las opciones en este orden cuando finaliza un trabajo o una tarea iniciada: 1. EWTROPTS RETCODE - crear un suceso de finalización del trabajo. 2. JCC - el suceso se pasa a JCC (comprobación de terminación de trabajo) si está activo. La JCC puede establecer un nuevo valor para el código de retorno. Después de procesar la JCC, el suceso pasa al controlador. El suceso alcanza el la cola de sucesos en el controlador. 3. Código de retorno 0 - Estado de operación establecido en C. O continuar comprobando. 4. ERROR TRACKING - Si los detalles de operación no especifican seguimiento de errores, el estado de operación se establece en C. O continuar comprobando. 5. NOERROR - Si el código de retorno coincide con una entrada NOERROR, el estado de operación se establece en C. O continuar comprobando. IBM Tivoli Workload Scheduler for z/OS comprueba todas las sentencias NOERROR y la palabra clave NOERROR de JTOPTS para buscar una entrada que coincida. 6. HIGHRC - Si el código de retorno es inferior o igual a HIGHRC, el estado de operación se establece en C. O continuar comprobando. IBM Tivoli Workload Scheduler for z/OS usa primero el valor HIGHRC en los detalles de operación. Si está en blanco, se utiliza JTOPTS HIGHRC. 7. ERRRES - Si el código de retorno coincide con una entrada ERRRES, el estado de operación se establece en A. Si no se produce ninguna coincidencia, el estado de operación se establece en E. Entonces puede producirse el proceso de recuperación. Recuperación IBM Tivoli Workload Scheduler for z/OS puede realizar acciones de recuperación para anomalías en trabajos y tareas iniciadas y anomalías en sistemas. Puede utilizar estas funciones de recuperación en IBM Tivoli Workload Scheduler for z/OS: Capítulo 2. Identificación de sentencias-parámetros de inicialización relacionados 183 Recuperación v Reinicio y limpieza v Recuperación automática de trabajos v Reinicio de la carga de trabajo. Para trabajos que utilicen scripts no centralizados y ejecutados en estaciones de trabajo no tolerantes a errores, consulte la palabra clave RCCONDSUC de la sentencia JOBREC descrita en el manual Planificación global con capacidades de tolerancia a errores.. Reinicio y limpieza Tabla 10. Parámetros relacionados con el reinicio y la limpieza Sentencia Palabras clave Descripción BATCHOPT RCLEANUP Habilita la limpieza de mantenimiento del almacén de datos local OPCOPTS RECOVERY No se realizará ninguna acción de recuperación automática hasta que se hayan completado las acciones de limpieza o se hayan desechado (cuando el tipo de limpieza es Inmediata) RCLEANUP Inicia las tareas de reinicio y de limpieza SNADEST Especifica la tabla de destinos de comprobador de seguimiento y almacén de datos usada para ubicar el almacén de datos usado por el registro de trabajo cuando se utiliza una conexión SNA XCFDEST Especifica la tabla de destinos de comprobador de seguimiento y almacén de datos usada para ubicar el almacén de datos usado por el registro de trabajo cuando se utiliza una conexión XCF CLNJOBPX Especifica el prefijo del nombre de trabajo que debe usarse para la limpieza autónoma CLNJOBCARD Especifica la información de la cuenta de trabajo usada al crear los trabajos de limpieza autónomos. DDALWAYS Lista los nombres de controlador de dispositivo que hacen que el paso pueda siempre volver a ejecutarse DDNEVER Lista los nombres de controlador de dispositivo que hacen que el paso no pueda volver a ejecutarse nunca DDNOREST Lista los nombres de controlador de dispositivo que hacen que el paso no pueda volver a reiniciarse DDPRMEM Contiene el nombre del miembro PDS de la biblioteca de parámetros que contiene la lista de nombres de controlador de dispositivo (DD) protegidos DDPROT Lista los nombres de controlador de dispositivo que identifican conjuntos de datos protegidos DSNPRMEM Contiene el nombre del miembro PDS de la biblioteca de parámetros que contiene la lista de nombres de conjuntos de datos protegidos DSNPROT Lista los nombres de conjuntos de datos protegidos DSTCLASS Especifica una clase JES cuando se usa JCC DSTDEST Especifica el destino que debe añadirse en JCL para crear una copia de salida del sistema para la almacén de datos DSTRMM RMM está activo y la limpieza utilizará la interfaz de programación de aplicaciones RMM STEPRESCHK Especifica la posibilidad de seleccionar un intervalo de reinicio de paso que anule temporalmente las comprobaciones de lógica de producto FLOPTS RCLOPTS 184 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Recuperación de registros de trabajo Recuperación de registros de trabajo Tabla 11. Parámetros relacionados con la recuperación de registros de trabajos del almacén de datos Sentencia Palabras clave Descripción OPCOPTS RCLEANUP Activa la tarea FL en el controlador para conectarse al almacén de datos FLOPTS SNADEST Especifica la tabla de destinos de comprobador de seguimiento y almacén de datos usada para ubicar el almacén de datos usado por el registro de trabajo cuando se utiliza una conexión SNA XCFDEST Especifica la tabla de destinos de comprobador de seguimiento y almacén de datos usada para ubicar el almacén de datos usado por el registro de trabajo cuando se utiliza una conexión XCF CTLLUNAM Especifica valores SNA que deben usarse para la conexión SNA al almacén de datos DSTGROUP, CTLMEM Especifica valores XCF que deben usarse para la conexión XCF al almacén de datos Recuperación automática de trabajos Cuando una operación finaliza como errónea, IBM Tivoli Workload Scheduler for z/OS puede realizar acciones de recuperación automáticamente o bajo solicitud desde la lista de finalización errónea en el diálogo de MCP. La recuperación espera la acción de limpieza, si es necesario. Tabla 12. Parámetros relacionados con la recuperación de trabajos automática Sentencia Palabras clave Descripción OPCOPTS RECOVERY Determina si el JCL es comprobado en busca de sentencias RECOVER cuando una operación finaliza de forma errónea RCLEANUP IBM Tivoli Workload Scheduler for z/OS realiza limpieza antes de que se inicie la recuperación si el tipo de limpieza de inmediato AROPTS EWTROPTS JTOPTS NOERROR Especifica opciones de recuperación STEPEVENTS Especifica cuándo IBM Tivoli Workload Scheduler for z/OS crea sucesos para finalizar pasos de trabajo RETCODE Código de retorno más alto o último ERRRES Estado de operación restablecido en A para estos códigos de error. No se realiza la recuperación. HIGHRC Realiza recuperación sólo si el código de retorno es mayor que HIGHRC NOERROR Códigos de error que no son errores. No se realiza la recuperación. Códigos de error que no son errores. No se realiza la recuperación. Estas opciones de trabajo en detalles de operación anulan temporalmente los valores de sentencia: v ERROR TRACKING v HIGHEST RETURNCODE v RESTART AND CLEANUP Capítulo 2. Identificación de sentencias-parámetros de inicialización relacionados 185 Reinicio de la carga de trabajo Reinicio de la carga de trabajo Tabla 13. Parámetros relacionados con el reinicio de cargas de trabajo Sentencia Palabras clave Descripción JTOPTS WSFAILURE Acciones a nivel de sistema para anomalías en estaciones de trabajo WSOFFLINE Acciones a nivel de sistema para estaciones de trabajo fuera de línea OPRESTARTDEFAULT Acción si el campo reiniciable en detalles de operación está en blanco OPREROUTEDEFAULT Acción si un campo que puede volver a enrutarse en detalles de operación está en blanco OFFDELAY Tiempo transcurrido antes de tomar acciones fuera de línea PULSE Tiempo entre reconocimientos para el controlador y los comprobador de seguimientos. Si un comprobador de seguimiento no responde a dos solicitudes de reconocimiento consecutivas, el controlador fuerza el destino fuera de línea. ROUTOPTS Estas opciones de trabajo en detalles de operación anulan temporalmente los valores de sentencia: v RESTARTABLE v REROUTABLE Rendimiento Estas sentencias y parámetros pueden afectar al rendimiento de IBM Tivoli Workload Scheduler for z/OS. Tabla 14. Parámetros relacionados con el rendimiento Sentencia Palabras clave AUDIT Descripción Especifica cuánta información de auditoría se produce ALERTS LATEOPER Usar sólo cuando las horas límite sean exactas AUTHDEF SUBRESOURCES Especifica los subrecursos que desea comprobar EWTROPTS STEPEVENTS Especifica cuándo IBM Tivoli Workload Scheduler for z/OS crea sucesos para finalizar pasos de trabajo PRINTEVENTS Especifica si IBM Tivoli Workload Scheduler for z/OS crea sucesos para tareas de impresión (tipo 4) HOLDJOB Especifica si IBM Tivoli Workload Scheduler for z/OS mantiene y libera trabajos en la cola JES EWWAIT Especifica el tiempo entre lecturas de un conjunto de datos de envío/liberación 186 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Rendimiento Tabla 14. Parámetros relacionados con el rendimiento (continuación) Sentencia Palabras clave Descripción JTOPTS BACKUP Especifica si se realiza una copia de seguridad del programa de control automáticamente y cuántos registros se escriben al registro JT entre copias de seguridad EVELIM Especifica la frecuencia de envío de mensajes de estadísticas relacionadas con la palabra clave STATMSG MAXJSFILE Especifica si se realiza una copia de seguridad de JS automáticamente y cuánto aumenta el archivo repositorio de JCL antes de que IBM Tivoli Workload Scheduler for z/OS realice una copia de seguridad QUEUELEN Especifica el número de operaciones que IBM Tivoli Workload Scheduler for z/OS inicia cuando la subtarea del analizador de estación de trabajo obtiene el bloqueo del programa de control STATIM Especifica cuándo se emiten los mensajes de estadísticas STATMSG Determina si IBM Tivoli Workload Scheduler for z/OS emite estadísticas de rendimiento para el plan actual, el gestor de sucesos, el servicio general y la tarea WSA TRACK Determina a qué trabajos realiza seguimiento IBM Tivoli Workload Scheduler for z/OS RCLEANUP Especifica si la función de reinicio y de limpieza está activa. El rendimiento se ve afectado cuando el usuario selecciona archivar las salidas del sistema del usuario por la mayoría de operaciones. VARSUB Determina qué trabajos son explorados en busca de variables y directivas de JCL LOGLINES Especifica el número máximo de líneas que el recuperador de registros de trabajo devuelve en un único registro de trabajo. OPCOPTS TOPOLOGY La cantidad de datos grabados en el registro de seguimiento de trabajos afecta a la frecuencia con la que IBM Tivoli Workload Scheduler for z/OS realiza una copia de seguridad de un plan actual. Recuerde esto cuando especifique un valor para la palabra clave BACKUP de JTOPTS. Generación de informes Estas sentencias y parámetros afectan a los informes producidos al planificar diariamente trabajos por lotes. Tabla 15. Parámetros relacionados con los informes Sentencia Palabras clave Descripción BATCHOPT DATEFORM Formato de fecha en informes DPROUT ddname del archivo en el que se graban los informes HDRS Serie de caracteres usados como cabeceras de informes PAGESIZE Número de líneas por página PLANHOUR Inicio de un período de plan para generación de informes PREVRES Resultados del período anterior (24 horas antes de PLANHOUR) JTOPTS PLANSTART Inicio de un período de plan para generación de informes RESOURCE FILTER Especifica de qué recursos especiales se debe informar Capítulo 2. Identificación de sentencias-parámetros de inicialización relacionados 187 Generación de informes También puede especificar en una descripción de estación de trabajo el ddname de un archivo al que la planificación diaria graba informes para la estación de trabajo. Este valor anula temporalmente DPROUT sólo para informes para la estación de trabajo. Seleccione qué tipos de informe produce IBM Tivoli Workload Scheduler for z/OS cuando usted ejecute un trabajo de planificación diaria. Supervisión de RODM El soporte deIBM Tivoli Workload Scheduler for z/OS para RODM le permite usar la supervisión de recursos establecida. Mediante suscripciones a RODM, puede supervisar el estado de los recursos reales usados por la operaciones de IBM Tivoli Workload Scheduler for z/OS. Tabla 16. Parámetros relacionados con RODM Sentencia Palabras clave Descripción OPCOPTS RODMTASK Inicia la subtarea RODM RODMPARM Especifica dónde se almacenan las sentencias RODMOPTS EWTRTASK Inicia un grabador de sucesos para recoger sucesos de recursos RODMOPTS Especifica parámetros de suscripción ROUTOPTS Especifica rutas a destinos de comprobador de seguimiento Usted especifica sentencias RODMOPTS sólo para el controlador. Es necesario un RODMOPTS distintos para cada suscripción. Usted especifica RODMTASK(YES) para un espacio de direcciones de IBM Tivoli Workload Scheduler for z/OS que se comunique con RODM, el cual debe iniciarse en la misma imagen de z/OS que el subsistema RODM. Un grabador de sucesos debe iniciarse en el mismo espacio de direcciones. Si la comunicación con RODM se realiza mediante un comprobador de seguimiento, usted especifica el destino del comprobador de seguimiento en RODMOPTS. El destino debe ser definido en ROUTOPTS. Proceso de salida Estas sentencias y parámetros determinan cómo IBM Tivoli Workload Scheduler for z/OS procesa la salida de impresión. Tabla 17. Parámetros relacionados con las salidas Sentencia Palabras clave Descripción EWTROPTS PRINTEVENTS Especifica si IBM Tivoli Workload Scheduler for z/OS crea sucesos para tareas de impresión (tipo 4) JCCOPTS CHKCLASS Clases SYSOUT que comprueba IBM Tivoli Workload Scheduler for z/OS JCWAIT Tiempo que JCC espera antes de volver a comprobar la cola SYSOUT para un trabajo MAXDELAY Tiempo máximo que JCC intenta encontrar SYSOUT SYSOUTDISP Especifica si se mantiene, suprime o se vuelve a poner en la cola SYSOUT después del proceso UMAXLINE Especifica cuántas líneas deben comprobarse en SYSOUT de usuario USYSOUT Especifica si se explora SYSOUT de usuario 188 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Proceso de salida Tabla 17. Parámetros relacionados con las salidas (continuación) Sentencia Palabras clave Descripción JTOPTS OUTPUTNODE Especifica qué nodo NJE para el que SYSOUT realiza un archivo de spool se usa para crear sucesos de terminación de trabajo JES2 Planificación global con capacidades de tolerancia a errores Estas sentencias y parámetros especifican configuraciones de red y definiciones de trabajos en el entorno global con capacidades de tolerancia a errores. Configuración de red Tabla 18. Parámetros relacionados con la configuración de la red Sentencia Palabras clave Descripción CPUREC CPUNAME Especifica el nombre de la estación de trabajo de IBM Tivoli Workload Scheduler. CPUOS Especifica el sistema operativo de la unidad central de proceso host relativa a la estación de trabajo de IBM Tivoli Workload Scheduler. CPUNODE Especifica el nombre nodo o la dirección IP de la unidad central de proceso. CPUTCPIP Especifica el número de puerto TCP de NETMAN en la unidad central de proceso actual. CPUDOMAIN Especifica el nombre del dominio de IBM Tivoli Workload Scheduler de la unidad central de proceso. CPUHOST Especifica el nombre de la unidad central de proceso host del agente. CPUACCESS Especifica el nombre del método de acceso. CPUTYPE Especifica el tipo de unidad central de proceso. CPUAUTOLNK Especifica el autoenlace entre el agente y el gestor de dominios. CPUFULLSTAT Especifica que el enlace del gestor de dominios opera en modalidad de Estado completo. CPURESDEP Especifica que el proceso de control de producción del agente opera en modalidad Resolver todas las dependencias. CPUSERVER Identifica un proceso de servidor (Mailman) en el gestor de dominios que envía mensajes al agente. CPULIMIT Especifica el número de trabajos que pueden ejecutarse al mismo tiempo en una unidad central de proceso. CPUTZ Especifica el huso horario local de la estación de trabajo no tolerante a errores. CPUUSER Especifica el usuario predeterminado para la estación de trabajo. SSLLEVEL Especifica si la estación de trabajo usa autenticación SSL cuando se conecta con su gestor de dominio. SSLPORT Define el puerto usado para escuchar conexiones SSL entrantes. FIREWALL Especifica si la comunicación entre una estación de trabajo y su gestor de dominio debe cruzar un cortafuegos. Capítulo 2. Identificación de sentencias-parámetros de inicialización relacionados 189 Planificación global con capacidades de tolerancia a errores Tabla 18. Parámetros relacionados con la configuración de la red (continuación) Sentencia Palabras clave Descripción SERVOPTS TPLGYPRM Define un miembro en el archivo identificado por la sentencia DD EQQPARM en el trabajo de inicio del servidor. El miembro contiene las opciones globales con tolerancia a errores definidas por la sentencia TOPOLOGY. Se usa para activar las capacidades globales en el servidor. PROTOCOL Identifica los tipos de comunicación usada por el servidor. SUBSYS Identifica el controlador para el que este servidor ha sido iniciado. BINDIR Especifica el directorio del sistema de archivos base donde se instalan los binarios, los catálogos y el resto de archivos instalados en el sistema de archivos y compartidos entre los subsistemas. CODEPAGE Especifica el nombre de la página de códigos de host. HOSTNAME Especifica el nombre de host o la dirección IP que será utilizada por el servidor en el entorno global con capacidades de tolerancia a errores. LOCALPSW Especifica si el ID de usuario y la contraseña que deben usarse para las estaciones de trabajo Windows deben encontrarse localmente cuando faltan en el archivo Symphony. LOGLINES Especifica el número máximo de líneas que el recuperador de registros de trabajo devuelve en un único registro de trabajo. PLANAUDITLEVEL Habilita o inhabilita la auditoría de plan para agentes distribuidos. PORTNUMBER Define el número de puerto TCP/IP usado por el servidor para comunicarse con los agentes distribuidos. SSLLEVEL Especifica si el servidor usa autenticación SSL. SSLPORT Define el puerto usado para escuchar conexiones SSL entrantes en el servidor. TCPIPJOBNAME Especifica el nombre de tarea iniciada en el TCP/IP usado por el servidor. TIMEZONE El huso horario local del sistema z/OS donde se ejecuta el controlador. TPLGYMEM Especifica el miembro PARMLIB donde están el dominio y la definición de unidad central de proceso. TRCDAYS Especifica el número de días que se guardan los archivos de rastreo antes de eliminarlos. USRMEM Especifica el miembro PARMLIB donde están las definiciones de usuario. WRKDIR Especifica la ubicación de los archivos de un subsistema. USRCPU Identifica la estación de trabajo en la que el usuario puede lanzar trabajos. Es válida sólo en estaciones de trabajo con Windows. USRNAM Especifica el nombre de usuario.Es válida sólo en estaciones de trabajo con Windows. USRPWD Especifica la contraseña de usuario. Es válida sólo en estaciones de trabajo con Windows. TOPOLOGY USRREC 190 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Planificación global con capacidades de tolerancia a errores Definiciones de trabajo Tabla 19. Parámetros relacionados con la definición de trabajos Sentencia Palabras clave Descripción JOBREC JOBSCR Especifica el nombre del script de shell o el archivo ejecutable que va a ejecutarse JOBCMD Especifica el nombre del mandato de shell que va a ejecutarse JOBUSR Especifica el nombre del usuario que envía el script o el mandato INTRACTV Especifica que un trabajo de Windows se ejecuta de modo interactivo el en escritorio de Windows RCCONDSUC Especifica una expresión booleana que determina el código de retorno (RC) necesario para considerar un trabajo como satisfactorio. OPTION Especifica la acción que IBM Tivoli Workload Scheduler for z/OS debe realizar cuando un trabajo finaliza repentinamente MESSAGE Especifica el texto de una solicitud de recuperación JOBCMD Especifica el nombre del mandato de shell que debe ejecutarse si el trabajo finaliza repentinamente JOBSCR Especifica el nombre del script de shell o archivo ejecutable que debe ejecutarse si el trabajo finaliza repentinamente JOBUSR Especifica el nombre del usuario que envía la acción del trabajo de recuperación JOBWS Especifica el nombre de la estación de trabajo INTRACTV Especifica que el trabajo de recuperación se ejecuta de modo interactivo en un escritorio de Windows RCCONDSUC Especifica una expresión booleana que determina el código de retorno necesario para considerar un trabajo de recuperación como satisfactorio. TABLES Identifica las tablas de variables que deben buscarse y el orden de búsqueda PREFIX Especifica un carácter no alfanumérico que precede a una variable BACKPREF Especifica un carácter no alfanumérico que delimita una variable para formar variables simples y compuestas VARFAIL Especifica si Tivoli Workload Scheduler for z/OS debe emitir un mensaje de error cuando se produce un error de sustitución de variable TRUNCATE Especifica si las palabras clave deben truncarse RECOVERY VARSUB Ajustes regionales Unos ajustes de página de códigos o de huso horario no existentes o incorrectos pueden provocar resultados inesperados, por ejemplo datos innecesarios en los registros de trabajos recuperados o tiempos de ejecución de trabajos incorrectos. Las siguientes secciones ofrecen una lista de comprobación sencilla para evitar esta clase de problemas. Página de códigos En el host, puede establecer la página de códigos especificando TOPOLOGY(CODEPAGE()) en las sentencias de servidor y de inicialización de lotes. El traductor de entrada y el agente no tolerante a errores (FTA) usan el valor especificado para convertir los datos recibidos, desde formato UTF-8 a formato EBCIDIC y a la inversa. Capítulo 2. Identificación de sentencias-parámetros de inicialización relacionados 191 Planificación global con capacidades de tolerancia a errores En el lado distribuido, para verificar la página de códigos activa puede usar mandatos específicos para el sistema operativo, por ejemplo el mandato chcp para Windows y locale para UNIX. Además: v Verifique que la variable de entorno TWS_TISDIR esté establecida como el nombre del directorio padre de Tivoli Workload Scheduler. v Para manejar trabajos con algunos caracteres nacionales en una estación de trabajo con Windows, añada el mandato chcp code_page al archivo TWS_home\jobmanrc, donde code_page es la página de códigos que incluye esos caracteres nacionales. Huso horario En un entorno global con capacidades de tolerancia a errores, el trabajo se planifica en términos de hora local del controlador. Cuando se añaden trabajos dependientes de la hora al archivo Symphony, el planificador convierte esa hora a la hora local de FTA. La conversión se realiza primero de hora local del controlador a GMT, y después de GMT a hora local de FTA. La conversión sólo tiene éxito si se producen las siguientes condiciones: v En el host: – Establece los relojes locales y GMT. – El directorio USS $BINDIR/zoneinfo contiene definiciones correctas de los husos horarios. – Para cada estación de trabajo a la que se hace referencia en la sentencia TPLGYMEM, las sentencias de servidor y de inicialización contienen un valor CPUREC(CPUTZ()) que coincide con el valor de huso horario del sistema operativo donde se ejecuta el agente. v En el lado distribuido, establece correctamente los valores de reloj y de huso horario para el sistema operativo que hace de host de cada agente. Integración de WLM Esta sentencia y estas palabras clave determinan cómo IBM Tivoli Workload Scheduler for z/OS se integra con Workload Manager (WLM) para ejecutar operaciones. Tabla 20. Integración de WLM - parámetros relacionados. Sentencia Palabras clave Descripción OPCOPTS WLM Ofrece información sobre la función de integración de la clase de servicio de WLM (nombre de clase, nombre de política). SECHECK Especifica si debe activarse la integración con el entorno de planificación de WLM y cómo debe hacerse. JESPLEX Especifica la lista de sistemas que componen el JESplex al que pertenece el comprobador de seguimiento. SYSPLEXID Especifica el número que identifica el sysplex al que pertenece el comprobador de seguimiento. SUPPRESSENF Especifica si la activación de salidas de escucha de ENF 57 y ENF 41 deben eliminarse. 192 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Supervisión externa Supervisión externa Estas sentencias y estas palabras clave especifican las opciones de configuración para que IBM Tivoli Workload Scheduler for z/OS funcione con Tivoli Business Systems Manager e IBM Tivoli Monitoring mediante el componente Tivoli Enterprise Portal. Tabla 21. Parámetros relacionados con la integración con supervisores externos Sentencia Palabras clave Descripción ALERTS MONALERT Define las condiciones bajo las que se envía una alerta genérica a IBM Tivoli Monitoring. MONOPER Este parámetro determina si las condiciones de error especificadas por la palabra clave MONALERT serán en efecto sólo para trabajos supervisados o para todos los trabajos. Se utiliza con IBM Tivoli Monitoring. EXTMON Especifica si está habilitada la integración con Tivoli Business Systems Manager. CODEPAGE Especifica la página de códigos de host que debe usarse para los datos recogidos por la tarea de supervisión MONHOSTNAME Identifica el nombre de host o la dirección IP de la aplicación de supervisión remota. Este parámetro se usa para la integración con el producto IBM Tivoli Monitoring. MONPORT Especifica el número de puerto de la aplicación de supervisión remota. Se utiliza para la integración con IBM Tivoli Monitoring. LOCHOSTNAME Especifica el nombre host local o la dirección IP que se usará para comunicarse con IBM Tivoli Monitoring. LOCPORT Especifica el número de puerto local usado por el controlador para comunicarse con IBM Tivoli Monitoring. BULKDISC Define si el descubrimiento masivo debe realizarse y cómo debe hacerse. Esta palabra clave se utiliza para la integración con IBM Tivoli Monitoring. CONNTIMEOUT Define el tiempo de espera excedido de establecimiento de conexión que debe usarse al comunicarse con IBM Tivoli Monitoring. OPERATION Especifica los tipos de operaciones que se seleccionan automáticamente para ser supervisadas por IBM Tivoli Monitoring y Tivoli Business Systems Manager. OPCOPTS MONOPTS MONPOL Capítulo 2. Identificación de sentencias-parámetros de inicialización relacionados 193 Supervisión externa 194 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Capítulo 3. Implementación de seguridad En este capítulo se describe cómo utilizar las características de seguridad de Tivoli Workload Scheduler for z/OS para proteger las funciones y los datos de Tivoli Workload Scheduler for z/OS. También contiene ejemplos de las distintas estrategias de seguridad. Antes de utilizar las características de seguridad de Tivoli Workload Scheduler for z/OS, debe definir y habilitar el entorno de seguridad. En la publicación Installation Guide se describe cómo hacerlo. Planificación de la implementación de seguridad Lea este capítulo para comprender cómo utilizar las características de seguridad de Tivoli Workload Scheduler for z/OS. Tenga en cuenta las tareas de la Tabla 22 al determinar los requisitos de seguridad. Tabla 22. Planificación de seguridad Tarea Página Tema Cómo Tivoli Workload Scheduler for z/OS verifica el acceso. 196 Determinar los ID de usuario que requieren acceso a Tivoli Workload Scheduler for z/OS. 197 Establecer convenios de denominación para recursos de Tivoli Workload Scheduler for z/OS. 198 Agrupar usuarios y recursos de RACF. 198 Revisar consideraciones generales de seguridad. 199 Determine si utiliza una estrategia centralizada o descentralizada. La estrategia determina hasta cierto punto los niveles de protección que necesita: 219 v Subsistema: quién puede acceder a Tivoli Workload Scheduler for z/OS. 201 v Recursos fijos: las funciones a las que puede acceder un usuario, por ejemplo, el diálogo AD, el diálogo MCP o la función RENOVAR. 201 200 v Subrecursos: los datos a los que puede acceder un usuario dentro de una función. Por ejemplo, puede permitir a un usuario acceder al diálogo AD pero sólo a determinadas aplicaciones. Revisar los requisitos de acceso y seguridad de la API si utiliza la API desde su propia TP o mediante la GUI de Tivoli Workload Scheduler for z/OS. 203 Revisar los requisitos de acceso y seguridad si utiliza Dynamic Workload Console. 205 Revisar los requisitos de acceso para los mandatos TSO de Tivoli Workload Scheduler for z/OS. 209 Cuando haya determinado los requisitos de seguridad, implemente el acceso de seguridad: © Copyright IBM Corp. 1991, 2011 195 Planificación de implementación de seguridad Tabla 23. Implementación de seguridad Tarea Página Tema Verificar si el entorno está configurado. Asegurarse de que: Consulte la publicación IBM Tivoli Workload Scheduler for z/OS Installation Guide v Se ha definido el ID de usuario de Tivoli Workload Scheduler for z/OS en la clase STARTED. v Se ha definido el nombre del subsistema Tivoli Workload Scheduler for z/OS como un recurso en la clase APPL. v Se ha utilizado la clase de recurso reservada para Tivoli Workload Scheduler for z/OS, IBMOPC. Especificar acceso al subsistema. 200 Especificar recursos fijos. 201 Especificar subrecursos. 201 Implementar acceso de seguridad mediante la API de Tivoli Workload Scheduler for z/OS, si utiliza esta función. 203 Implementar acceso de seguridad mediante 203 el servidor de Tivoli Workload Scheduler for z/OS, si utiliza esta función. Especificar subrecursos en la sentencia AUTHDEF. 22 Especificar nombres de recursos en la sentencia AUDIT, si necesita información de auditoría. 18 Cómo Tivoli Workload Scheduler for z/OS verifica la autorización de acceso Para verificar la autorización de acceso, Tivoli Workload Scheduler for z/OS utiliza la macro RACROUTE. Esta macro tiene una interfaz de objetivo general al producto de seguridad mediante SAF (recurso de autorización del sistema). El producto de seguridad puede ser RACF o cualquier otro producto que funcione con SAF. En este capítulo, los mandatos de RACF muestran cómo Tivoli Workload Scheduler for z/OS se comunica con un producto de seguridad. Para verificar una autorización de usuario, Tivoli Workload Scheduler for z/OS utiliza la macro RACROUTE para invocar el direccionador z/OS de SAF. Direcciona de forma condicional el control a RACF, si está presente. Las opciones de RACROUTE que utiliza Tivoli Workload Scheduler for z/OS invocan estas funciones de RACF: RACINIT 196 Proporciona identificación y verificación de usuario de RACF cuando se solicitan servicios de Tivoli Workload Scheduler for z/OS. (Tivoli Workload Scheduler for z/OS no tiene su propio panel de inicio de sesión o ID de usuario.) IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Cómo verificar la autorización de acceso RACLIST Crea perfiles en almacenamiento para recursos definidos por RACF, lo que mejora el rendimiento para la comprobación de autorización de recursos. Nota: Algunos productos de seguridad no dan soporte a esta función. Si utiliza un producto de este tipo, RACLIST es en efecto una no operación. RACHECK Proporciona comprobación de autorización al solicitar acceso a un recurso protegido por RACF, por ejemplo, al acceder a: v Datos (por ejemplo, el plan actual) v Una función (por ejemplo, RENOVAR) Para obtener más información sobre los recursos que puede proteger, consulte “Funciones y datos que puede proteger” en la página 210. FRACHECK Proporciona comprobación de autorización en el subsistema Tivoli Workload Scheduler for z/OS. Nota: Los productos de seguridad que no dan soporte a RACLIST convierten las solicitudes FRACHECK en la solicitud RACHECK correspondiente. Esto podría afectar seriamente el rendimiento de algunas funciones de diálogo de IBM Tivoli Workload Scheduler for z/OS. Identificación de usuarios RACF controla la interacción entre usuarios y recursos. Puede definir recursos y el nivel de acceso permitido por los usuarios a estos recursos en perfiles de RACF. Un usuario es un ID de usuario alfanumérico que RACF asocia con el usuario. Tivoli Workload Scheduler for z/OS necesita acceder a recursos no IBM Tivoli Workload Scheduler for z/OS para el trabajo que planifica. El ID de usuario asociado con IBM Tivoli Workload Scheduler for z/OS se puede obtener de: v El espacio de direcciones de Tivoli Workload Scheduler for z/OS que accede a conjuntos de datos utilizados por el trabajo que planifica, y que envía trabajo y emite mandatos de JES y MVS. v El parámetro user= de la tarjeta JOB de un trabajo por lotes. v La salida de envío de trabajos de Tivoli Workload Scheduler for z/OS, EQQUX001, a la que se invoca cuando Tivoli Workload Scheduler for z/OS va a enviar un trabajo o iniciar una tarea iniciada, y que puede devolver un ID de usuario. v La sentencia USRREC, que especifica el nombre y la contraseña del usuario en una estación de trabajo Windows soportada. v La sentencia LOCALPSW, que especifica si el nombre y la contraseña de un usuario en una estación de trabajo Windows están definidos en z/OS utilizando la sentencia USRREC (LOCALPSW establecido en NO) o en la estación de trabajo Windows utilizando un archivo local (LOCALPSW establecido en YES). Si establece LOCALPSW en YES, el planificador busca en primer lugar la sentencia USRREC y, a continuación, el archivo local. v La palabra clave USERMAP de la sentencia SERVOPTS. Los ID de usuario que acceden a los recursos de Tivoli Workload Scheduler for z/OS pueden ser los siguientes: Capítulo 3. Implementación de seguridad 197 Identificación de usuarios v Un ID de usuario de TSO que accede a los diálogos de Tivoli Workload Scheduler for z/OS, envía trabajos por lotes que acceden a recursos de Tivoli Workload Scheduler for z/OS y emite los mandatos TSO de Tivoli Workload Scheduler for z/OS. v Un espacio de direcciones de Tivoli Workload Scheduler for z/OS, al que se debe permitir acceso a los recursos de Tivoli Workload Scheduler for z/OS. v Otros espacios de direcciones de tarea iniciada que pasan solicitudes a un espacio de direcciones de Tivoli Workload Scheduler for z/OS. v Un ID de usuario proporcionado por un programa de transacción (TP) que utiliza la API de Tivoli Workload Scheduler for z/OS para comunicarse con el controlador. v Un ID de usuario definido por la palabra clave USERMAP de la sentencia SERVOPTS para trabajar con Dynamic Workload Console. Establecimiento de convenios de denominación para recursos de IBM Tivoli Workload Scheduler for z/OS La utilización de convenios de denominación coherentes permite agrupar usuarios y ayuda a reducir el número de nombres de recursos de RACF que necesita. Los estándares de nombres son especialmente importantes si restringe el acceso a los datos de Tivoli Workload Scheduler for z/OS especificando subrecursos. Tenga en cuenta estos recursos al establecer convenios de denominación: v ID de aplicación v ID de definición de grupo v ID de propietario v ID de grupo de autorización v ID de calendario v Nombre del periodo v Nombre de operación v Nombre de la estación de trabajo v ID de tabla de variables de JCL v Nombre de recurso especial Además, tenga en cuenta los recursos que utiliza para restringir el acceso. Por ejemplo, puede proteger las descripciones de las aplicaciones mediante el ID de aplicación, el ID de propietario y el ID de grupo de autorización. Nota: Algunos campos de Tivoli Workload Scheduler for z/OS que se pueden utilizar para la verificación de seguridad permiten caracteres que no son aceptables en RACF. Por ejemplo, los caracteres para punto y coma, coma y espacio en blanco no se pueden especificar en un nombre de recurso de RACF independientemente de las especificaciones FIRST y OTHER en la macro ICHERCDE, pero son aceptables como parte de un ID de propietario de Tivoli Workload Scheduler for z/OS. Agrupación de usuarios y recursos de RACF Se recomienda encarecidamente que no otorgue acceso a usuarios individuales, sino que intente agrupar los usuarios en distintas categorías. A continuación, puede definir un grupo de usuarios de RACF para cada categoría de usuarios. Con grupos de usuarios de RACF, no es necesario cambiar las listas de accesos de distintos perfiles con tanta frecuencia. Cuando deba realizar un cambio, añada o elimine un ID de usuario en el grupo, o mueva el ID de usuario a otro grupo. 198 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Agrupación de usuarios y recursos de RACF Estas categorías se utilizan en muchas instalaciones de Tivoli Workload Scheduler for z/OS: v Planificadores v Operadores de estación de trabajo v Jefes de turnos de Tivoli Workload Scheduler for z/OS v Operadores de sala de máquinas v Soporte del sistema Tivoli Workload Scheduler for z/OS Además, tenga en cuenta la utilización de perfiles genéricos al especificar nombres de recursos de RACF. Los recursos protegidos por perfiles genéricos tienen nombres similares y requisitos de seguridad idénticos. Consideraciones generales de seguridad Tivoli Workload Scheduler for z/OS envía trabajos para usuarios e inicia tareas iniciadas. Los usuarios se comunican con Tivoli Workload Scheduler for z/OS mediante diálogos de ISPF en ejecución bajo TSO o mediante trabajos por lotes. Estos diálogos y trabajos por lotes utilizan el subsistema Tivoli Workload Scheduler for z/OS. Es posible que algunos usuarios no necesiten asignar, suprimir o reorganizar los conjuntos de datos de Tivoli Workload Scheduler for z/OS. Los recursos de RACF y Tivoli Workload Scheduler for z/OS permiten proporcionar a usuarios individuales el nivel de acceso que necesitan al mismo tiempo que protegen los datos frente a daños accidentales o malintencionados. Tivoli Workload Scheduler for z/OS necesita acceso de actualización a catálogos y acceso de modificación a conjuntos de datos para todos los trabajos de los que realiza un seguimiento, lo que utiliza la función de reinicio y limpieza. Pero si permite que Tivoli Workload Scheduler for z/OS acceda a todos los sistemas, es posible que un usuario obtenga acceso no autorizado mediante Tivoli Workload Scheduler for z/OS, ya que cualquier trabajo enviado por Tivoli Workload Scheduler for z/OS puede acceder a los datos. De esta forma, si utiliza RACF 1.9 o posterior, tenga en cuenta el envío de trabajo sustituto para autorizar los trabajos enviados por Tivoli Workload Scheduler for z/OS. Especificando Tivoli Workload Scheduler for z/OS como usuario sustituto para cada uno de los sistemas, puede evitar violaciones de otros usuarios. Para obtener más información, consulte las publicaciones Installation Guide y RACF Administrator's Guide Si utiliza los recursos de espera dinámica de Tivoli Workload Scheduler for z/OS, tenga en cuenta el entorno de seguridad en cualquier sistema en espera potencial. Si se invoca la espera, debe acceder a los conjuntos de datos, diálogos, recursos y subrecursos de Tivoli Workload Scheduler for z/OS desde el sistema en espera. Si utiliza la función de reinicio de carga de trabajo, asegúrese de que el trabajo redireccionado pueda acceder a los recursos necesarios en el sistema donde se realiza el trabajo. El trabajo de Tivoli Workload Scheduler for z/OS que se envía en un destino determinado tiene la autorización de Tivoli Workload Scheduler for z/OS en ese destino o, si se utiliza la salida de EQQUX001, la autorización del usuario que realiza el envío. Puede realizar un seguimiento del acceso a los recursos de Tivoli Workload Scheduler for z/OS especificando parámetros en la sentencia de inicialización AUDIT. Cuando un usuario accede a un recurso nominado, se graba un registro en el conjunto de datos del registro de seguimiento de trabajos actual. La sentencia AUDIT se describe en “AUDIT” en la página 18. Capítulo 3. Implementación de seguridad 199 Control del acceso a Tivoli Workload Scheduler for z/OS Control del acceso a Tivoli Workload Scheduler for z/OS La seguridad de Tivoli Workload Scheduler for z/OS implica tres niveles de protección: v El subsistema Tivoli Workload Scheduler for z/OS determina si un usuario puede establecer una comunicación con Tivoli Workload Scheduler for z/OS. v Los recursos fijos protegen las funciones en Tivoli Workload Scheduler for z/OS; por ejemplo, modificando el plan actual o solicitando una copia de seguridad de un conjunto de datos de recursos. v Los subrecursos protegen los datos de Tivoli Workload Scheduler for z/OS. El nivel de acceso proporcionado a un usuario en un nivel determina el acceso predeterminado que tiene el usuario en los demás niveles. Por ejemplo, si un usuario tiene acceso de actualización al subsistema Tivoli Workload Scheduler for z/OS, este usuario tiene, de manera predeterminada, acceso de actualización a todos los recursos fijos. El acceso de un usuario a los recursos fijos determina a su vez el acceso predeterminado a los subrecursos. Cuando no se ha protegido específicamente un recurso, se utiliza el valor predeterminado. Si utiliza la API de Tivoli Workload Scheduler for z/OS, también puede utilizar las funciones de seguridad de APPC/z/OS para proteger el acceso al controlador. Consulte “Control del acceso a Tivoli Workload Scheduler for z/OS desde APPC” en la página 203 para obtener más información. Revise cuidadosamente los requisitos de seguridad y especifique los niveles de protección que requiera. No especifique niveles adicionales de protección si no son necesarios. Control del acceso al subsistema Tivoli Workload Scheduler for z/OS Especifique el nombre del subsistema host Tivoli Workload Scheduler for z/OS como recurso en la clase APPL con el acceso predeterminado NONE. Puede controlar de forma efectiva el control a las funciones de diálogo de Tivoli Workload Scheduler for z/OS permitiendo o denegando a los usuarios el acceso al recurso del subsistema. Si el usuario ejecuta trabajos por lotes que utilizan el subsistema, estos trabajos por lotes tienen restricciones similares. Por ejemplo, para permitir sólo al grupo de usuarios OPCUGRP acceso al subsistema OPCC y otorgar autorización de actualización, especifique: RDEFINE APPL OPCC UACC(NONE) PERMIT OPCC ID(OPCUGRP) ACCESS(UPDATE) CLASS(APPL) Cuando un usuario del diálogo intenta acceder a un subsistema (por ejemplo, OPCC), RACF mira en la clase APPL para ver si se ha definido este recurso. Si el recurso se ha definido y la autorización de acceso es de lectura o actualización, el usuario puede continuar. Si el recurso no se ha definido, el usuario del diálogo tiene acceso de actualización a todos los recursos fijos de Tivoli Workload Scheduler for z/OS. Cualquier usuario de TSO con acceso de lectura o actualización al recurso del subsistema en la clase APPL de RACF puede entrar en diálogos de Tivoli Workload Scheduler for z/OS. De manera predeterminada, el usuario tiene el mismo acceso (de lectura o grabación) a recursos fijos de Tivoli Workload Scheduler for z/OS. 200 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Control del acceso a recursos fijos Control del acceso a recursos fijos de Tivoli Workload Scheduler for z/OS Probablemente deseará poner más restricciones sobre el acceso a los recursos. Por ejemplo, es posible que un usuario necesite acceso de actualización al archivo de biblioteca de trabajos y JCL pero que necesite acceso de lectura a los datos de calendario. Puede conseguir este nivel de control especificando recursos fijos de Tivoli Workload Scheduler for z/OS en una clase de recurso general utilizada por Tivoli Workload Scheduler for z/OS. RACF proporciona una clase de recurso reservado de IBM, IBMOPC. Para ver una lista de comprobación sobre la utilización de clases de RACF, consulte la descripción del parámetro CLASS en “AUTHDEF” en la página 22. Nota: Si se impide a un usuario acceder a un conjunto de datos, es posible que no se evite que el usuario actualice los datos del conjunto de datos. Cuando se utilizan diálogos de Tivoli Workload Scheduler for z/OS, los usuarios acceden a los datos de Tivoli Workload Scheduler for z/OS mediante el subsistema de Tivoli Workload Scheduler for z/OS con el nivel de acceso del subsistema. En la Tabla 26 en la página 210 se muestran los recursos fijos que puede proteger. Cuando define los nombres de recursos de los recursos fijos de Tivoli Workload Scheduler for z/OS que desea proteger, otorga un nivel de acceso a los usuarios. Estos niveles de acceso tienen un significado: ACCESS(NONE) ACCESS(READ) ACCESS(UPDATE) ACCESS(ALTER) no tiene soporte de código en IBM Tivoli Workload Scheduler for z/OS para recursos fijos o subrecursos. ALTER proporciona el mismo nivel de acceso que UPDATE. Si cambia el nivel de acceso de un usuario o elimina completamente el perfil del usuario, el cambio no entrará en vigor hasta que el usuario salga del diálogo de IBM Tivoli Workload Scheduler for z/OS e intente volver a entrar en él. Recuerde que el acceso predeterminado a los recursos fijos de IBM Tivoli Workload Scheduler for z/OS lo determina el nivel de acceso del usuario al subsistema IBM Tivoli Workload Scheduler for z/OS. RACF no comprueba si hay una clase de RACF hasta que se activa esa clase. Puede activar una clase utilizando el parámetro ACTIVATE del mandato SETROPTS. Control del acceso a subrecursos de Tivoli Workload Scheduler for z/OS Puede restringir el acceso a los datos de IBM Tivoli Workload Scheduler for z/OS especificando subrecursos. Este nivel de protección es útil si desea permitir que distintos usuarios accedan a una función determinada de IBM Tivoli Workload Scheduler for z/OS, al mismo tiempo que permite el acceso de los usuarios sólo a sus propios datos de IBM Tivoli Workload Scheduler for z/OS. Por ejemplo, es posible que un usuario no necesite acceso a todas las aplicaciones, sólo a las aplicaciones de nómina. Capítulo 3. Implementación de seguridad 201 Control del acceso a subrecursos Si no especifica subrecursos, el acceso a los datos lo determina el acceso de un usuario a los recursos fijos o, si no se han definido recursos fijos, el acceso del usuario al subsistema IBM Tivoli Workload Scheduler for z/OS. Para implementar protección específica de datos de IBM Tivoli Workload Scheduler for z/OS, debe: v Proporcionar a los usuarios acceso al recurso fijo que es propietario del subrecurso. v Añadir el subrecurso a la lista de SUBRESOURCES de la sentencia AUTHDEF. v Definir en RACF el nombre del recurso de RACF que corresponde al nombre del subrecurso de IBM Tivoli Workload Scheduler for z/OS. v Configure el perfil de RACF necesario para el recurso. En la Tabla 26 en la página 210 se muestran los subrecursos que puede proteger. Si cambia un perfil para un subrecurso mientras IBM Tivoli Workload Scheduler for z/OS está activo, el cambio no entra en vigor de forma inmediata. Las tres formas de hacer que el cambio sea efectivo son: v Detener y reiniciar IBM Tivoli Workload Scheduler for z/OS. v Utilizar el mandato modify (F xxxx,P=GEN seguido por F xxxx,S=GEN) para detener y reiniciar la subtarea de servicio general. v Seleccionar Funciones de servicio (elemento 9 del menú principal del diálogo de IBM Tivoli Workload Scheduler for z/OS) y, a continuación, seleccionar Recursos de RACF. RACF no comprueba si hay una clase de RACF hasta que se activa esa clase. Puede activar una clase utilizando el parámetro CLASSACT del mandato SETROPTS. Para habilitar la comprobación genérica de perfiles, defina la clase en el parámetro GENERIC de SETROPTS. Subrecursos y recursos de RACF de Tivoli Workload Scheduler for z/OS La sentencia AUTHDEF utiliza el nombre de subrecurso de IBM Tivoli Workload Scheduler for z/OS para activar la comprobación de RACF para un subrecurso de IBM Tivoli Workload Scheduler for z/OS. Por ejemplo, si desea que IBM Tivoli Workload Scheduler for z/OS verifique la autorización para descripciones de aplicaciones comprobando el nombre de aplicación, debe especificar el valor AD.ADNAME en la palabra clave SUBRESOURCES de la sentencia AUTHDEF. El nombre de recurso que a continuación RACF comprueba consta de un código de tres caracteres que identifica el subrecurso, seguido por un nombre que especifica los datos específicos que se deben proteger. Por ejemplo, para proteger descripciones de aplicaciones cuyo nombre de aplicación sea PAYROLL, debe definir un recurso de RACF, ADA.PAYROLL, en la clase de recurso de RACF que esté especificado en la sentencia AUTHDEF. A continuación se presenta un ejemplo que muestra cómo proteger el archivo de biblioteca de trabajos (JS) y JCL. En este ejemplo se asume que: v El archivo está protegido frente a actualizaciones pero lo puede leer cualquier usuario. v El ID de propietario se utiliza para proteger el acceso. En la Tabla 26 en la página 210 se muestran los otros nombres que puede seleccionar para proteger el recurso fijo de JS. v El usuario CASHIER tiene acceso de actualización a los datos con el propietario PAYROLL pero sólo tiene acceso de lectura a otros datos. 202 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Subrecursos y recursos de RACF v OPCCLASS es la clase de recurso de RACF utilizada para proteger recursos de IBM Tivoli Workload Scheduler for z/OS. Este nombre se especifica en la sentencia AUTHDEF. v Los recursos necesarios no se han definido. Para implementar la protección: 1. Defina el recurso fijo que es propietario del subrecurso y proporcione acceso de lectura universal a éste: RDEFINE (OPCCLASS) JS UACC(READ) 2. Proporcione al usuario CASHIER acceso de actualización al recurso fijo de JS: PERMIT JS ID(CASHIER) ACCESS(UPDATE) CLASS(OPCCLASS) 3. Defina un recurso de RACF, JSO.PAYROLL, en RACF y proporcione acceso de lectura universal a JSO.PAYROLL: RDEFINE (OPCCLASS) JSO.PAYROLL UACC(READ) JSO es el código de 3 caracteres que utiliza RACF para JS.OWNER. 4. Proporcione al usuario CASHIER acceso de actualización a JSO.PAYROLL: PERMIT JSO.PAYROLL ID(CASHIER) ACCESS(UPDATE) CLASS(OPCCLASS) 5. Defina un subrecurso JSO.* en RACF y proporcione acceso de lectura universal a este subrecurso: RDEFINE (OPCCLASS) JSO.* UACC(READ) Esta regla impide que el usuario CASHIER actualice JCL en apariciones que no tengan el ID de propietario PAYROLL. 6. Empiece a comprobar el subrecurso JS.OWNER especificando JS.OWNER en la palabra clave SUBRESOURCES de la sentencia AUTHDEF. El acceso predeterminado de un usuario a los subrecursos de IBM Tivoli Workload Scheduler for z/OS lo determina el acceso del usuario a los recursos fijos de IBM Tivoli Workload Scheduler for z/OS. Si basa los subrecursos en nombres de aplicaciones o ID de propietario y estos no tienen estándares de denominación coherentes, es posible que necesite cientos e incluso miles de perfiles de RACF. Esto haría que los recursos fueran difíciles de mantener. También ralentizaría el proceso de IBM Tivoli Workload Scheduler for z/OS, especialmente durante el arranque cuando se leen todos los perfiles. Puede reducir drásticamente el número de perfiles que necesita utilizando estándares de denominación coherentes o perfiles genéricos de RACF, o ambos. Notas: 1. Si define sólo recursos fijos, un usuario que solicite una lista de apariciones verá los nombres de todas las apariciones. Si define subrecursos, sólo se mostrarán en la lista las apariciones a las que el usuario tiene acceso. De esta forma, dos usuarios de IBM Tivoli Workload Scheduler for z/OS que soliciten la misma lista en el mismo panel podrían ver listas distintas. 2. Si utiliza la protección de subrecursos, puede controlar el número de violaciones de acceso registradas para solicitudes de lista mediante la palabra clave LISTLOGGING de AUTHDEF. Control del acceso a Tivoli Workload Scheduler for z/OS desde APPC Lea la siguiente información si utiliza cualquiera de las interfaces de usuario de IBM Tivoli Workload Scheduler for z/OS para acceder a IBM Tivoli Workload Scheduler for z/OS utilizando APPC. Las interfaces incluyen: Capítulo 3. Implementación de seguridad 203 Control del acceso desde APPC v La API de IBM Tivoli Workload Scheduler for z/OS, desde su propio programa de transacción o desde la GUI de Tivoli Workload Scheduler for z/OS v El servidor de IBM Tivoli Workload Scheduler for z/OS, desde sus propios programas PIF o diálogos de ISPF, o la GUI para Descripción de aplicaciones. El acceso a IBM Tivoli Workload Scheduler for z/OS mediante la API o el servidor se puede controlar de dos formas distintas: mediante seguridad proporcionada por: v APPC/z/OS y RACF v IBM Tivoli Workload Scheduler for z/OS y RACF APPC/z/OS y RACF El componente APPC/z/OS crea un entorno de seguridad que se pasa al planificador de IBM Tivoli Workload Scheduler for z/OS para el ID de usuario que asigna la conversación. APPC/z/OS requiere que una conversación pueda ser fiable o no fiable. Si la conversación se define como fiable, se asume que se ha verificado el entorno de seguridad y que la asignación se ha aceptado. Si una conversación no es fiable, se debe pasar el entorno de seguridad como parte de la asignación. El acceso a IBM Tivoli Workload Scheduler for z/OS mediante diálogos de ISPF o PIF utiliza una asignación fiable. El acceso a IBM Tivoli Workload Scheduler for z/OS mediante la API o la GUI de Tivoli Workload Scheduler for z/OS utiliza una asignación no fiable. Como nivel adicional de seguridad, estos accesos utilizan un programa de transacción que debe tener un tipo de seguridad de PGM o SAME. Para la GUI de Tivoli Workload Scheduler for z/OS, estas definiciones se crean en Communications Manager. También debe asegurarse de que existe un perfil de usuario de RACF en la base de datos de RACF para el ID de usuario que se pasa en una solicitud de asignación. Puede utilizar las funciones de seguridad de APPC/z/OS para controlar: v El acceso a las unidades lógicas v El acceso para la comunicación entre unidades lógicas v El acceso a los TP v La Seguridad dentro de la red IBM Tivoli Workload Scheduler for z/OS reconoce los siguientes nombres de TP: Nombre EQQTRK EQQAPI EQQDIA Proporcionado por Rastreadores que se comunican con el controlador mediante APPC Programas de usuario (ATP) que se comunican con IBM Tivoli Workload Scheduler for z/OS mediante la API Diálogos de ISPF de IBM Tivoli Workload Scheduler for z/OS Consulte la publicación APPC Management para obtener información detallada sobre la protección del entorno APPC/z/OS. ICSF/MVS Programmer's Guide describe cómo se puede proteger la información que pasa a través de la red. API de Tivoli Workload Scheduler for z/OS y RACF IBM Tivoli Workload Scheduler for z/OS realiza comprobación de seguridad en el controlador para todos los TP que utilizan la API. Para establecer una conversación, el TP saliente debe proporcionar un ID_usuario y una contraseña y, opcionalmente, un perfil que indique el grupo de usuarios de RACF. El ID_usuario debe tener acceso al recurso del subsistema IBM Tivoli Workload Scheduler for z/OS, que está definido en la clase APPL. 204 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Control del acceso desde APPC Un usuario requiere este acceso a recursos fijos para solicitudes de la API: GET Lectura del programa de control. También es necesaria la lectura de SR para recuperar información del recurso especial. PUT Actualización del programa de control. Es necesaria la actualización de RL para cambiar el estado de las operaciones o emitir mandatos de lista de preparados como por ejemplo MH o NOP. Es necesaria la actualización de EXEC para utilizar el mandato EXEC. DEL Actualización del programa de control. CREATE IBM Tivoli Workload Scheduler for z/OS no da soporte a la comprobación de seguridad para solicitudes CREATE ya que una solicitud podría dirigirse a más de un subsistema IBM Tivoli Workload Scheduler for z/OS en los que las reglas de seguridad son distintas. Puede impedir la utilización no autorizada de solicitudes CREATE mediante los mecanismos de seguridad de APPC/z/OS protegiendo la unidad lógica y el nombre de TP. Si protege los datos de IBM Tivoli Workload Scheduler for z/OS especificando subrecursos, los usuarios deben tener el acceso adecuado a los subrecursos. En la Tabla 26 en la página 210 se muestran los subrecursos que puede especificar para cada recurso fijo. Control del acceso a Tivoli Workload Scheduler for z/OS utilizando Dynamic Workload Console Lea la siguiente información si utiliza Dynamic Workload Console para acceder a Tivoli Workload Scheduler for z/OS utilizando TCP/IP. El conector z/OS realiza una comprobación de seguridad cuando un usuario intenta utilizar Dynamic Workload Console de IBM Tivoli Workload Scheduler for z/OS, comprobando el ID de usuario y la contraseña. El conector z/OS asocia cada ID de usuario y contraseña con un administrador. Los recursos de Tivoli Workload Scheduler for z/OS los protege actualmente RACF. El usuario de Dynamic Workload Console debe necesitar especificar sólo una única combinación de ID de usuario y contraseña y no proporcionar dos niveles de comprobación de seguridad (en el nivel de conector de z/OS y de nuevo en el nivel de Tivoli Workload Scheduler for z/OS). El modelo de seguridad se basa en que la seguridad del conector z/OS maneja la verificación de usuario inicial y, al mismo tiempo, obtiene un ID de usuario RACF válido correspondiente. Esto posibilita al usuario trabajar con el entorno de seguridad en z/OS. La seguridad de z/OS se basa en una tabla que correlaciona el administrador con el ID de usuario de RACF. Cuando un conector z/OS se conecta con Tivoli Workload Scheduler for z/OS, el administrador del conector z/OS se correlaciona con el ID de usuario correspondiente. Por lo tanto, asegúrese de que el ID de administrador se asocie con un ID de usuario de RACF en el parámetro USERMAP de la sentencia de inicialización SERVOPTS. El ID de usuario de RACF no necesita tener permisos concretos para los recursos de Tivoli Workload Scheduler for z/OS. Para obtener detalles sobre cómo correlacionar un ID de usuario con un ID de Capítulo 3. Implementación de seguridad 205 Control del acceso utilizando Dynamic Workload Console usuario de RACF, consulte “Utilización de un nuevo parámetro de inicialización de servidor para asociar un ID de usuario de RACF” en la página 208. Para las operaciones realizadas con Dynamic Workload Console, asegúrese de que el ID de usuario de Dynamic Workload Console esté asociado con un ID de usuario de RACF que corresponda. El ID de usuario RACF debe tener los permisos necesarios para acceder a los recursos de Tivoli Workload Scheduler for z/OS. El servidor Tivoli Workload Scheduler for z/OS utiliza el ID de usuario de RACF para crear el entorno de RACF a fin de permitir al usuario acceder a los servicios de Tivoli Workload Scheduler for z/OS. Puede obtener el ID de usuario de RACF de una de las formas siguientes: v Utilizando la clase de recurso de RACF TMEADMIN predefinida y proporcionada por Tivoli. Para obtener detalles, consulte el “Creación de la clase TMEADMIN para asociar a un ID de usuario de RACF”. v Utilizando un nuevo parámetro de inicialización del servidor (SERVOPTS USERMAP) para definir un miembro en el archivo identificado por la sentencia EQQPARM DD en el trabajo de inicio del servidor. Si se especifica el parámetro USERMAP para la sentencia SERVOPTS, la clase de RACF TMEADMIN se ignora. Para obtener detalles, consulte el “Utilización de un nuevo parámetro de inicialización de servidor para asociar un ID de usuario de RACF” en la página 208. Este ejemplo muestra el proceso de autenticación realizado por el conector z/OS cuando se conecta como usuario de Dynamic Workload Console. Suponga que: v El nombre del host en el que se ejecuta el conector de z/OS es ROME1. v El usuario del conector z/OS se llama ZCONN1. v El ID de usuario de Dynamic Workload Console con el que se conecta con el conector z/OS es GRAPHUSR. Cuando GRAPHUSR se conecta con el conector z/OS, este ID de usuario se autentica en ROME1. Además, ZCONN1 se autentica en el motor de z/OS proporcionando las credenciales siguientes: USER ZCONN1-AT-ROME1-domain RACFUSER (TSOuser) donde TSOuser es el ID de usuario de TSO con el que se ejecutan los diálogos de Tivoli Workload Scheduler for z/OS. Cuando GRAPHUSR lleva a cabo una operación, el conector z/OS utiliza estas credenciales y por lo tanto es necesario que tanto GRAPHUSR como ZCONN1 se asocien a un ID de usuario RACF. El ID de usuario RACF asociado al usuario del conector z/OS no necesita tener permisos concretos para los recursos de Tivoli Workload Scheduler for z/OS, mientras que el ID de usuario de RACF asociado al usuario de la consola necesita los permisos para realizar las operaciones necesarias. Creación de la clase TMEADMIN para asociar a un ID de usuario de RACF 1. Asegúrese de que el sistema operativo tiene la característica Servidor de seguridad. 2. Cree la clase TMEADMIN para correlacionar el ID de administrador y el nombre de host con el ID de usuario de RACF. 206 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Control del acceso utilizando Dynamic Workload Console Nota: Si RACF es el producto de seguridad y el sistema operativo no tiene la característica Servidor de seguridad, puede utilizar los ejemplos proporcionados para crear lo siguiente: v clase de RACF TMEADMIN EQQ9RFDE. Utilice la macro siguiente, a la que puede acceder en el miembro EQQ9RFDE de la biblioteca SEQQSAMP: TMEADMIN ICHERCDE CLASS=TMEADMIN, ID=129, MAXLNTH=246, FIRST=ALPHANUM, OTHER=ANY, POSIT= 26, OPER=NO, DFTUACC=NONE, DFTRETC=8, RACLIST=ALLOWED, GENLIST=ALLOWED v Tabla de direccionador de RCAF EQQ9RF01. Utilice la macro siguiente, a la que puede acceder en el miembro EQQ9RF01 de la biblioteca SEQQSAMP: TAB18 ICHRFRTB CLASS=TMEADMIN,ACTION=RACF 3. Utilizando la clase de RCAF TMEADMIN, correlacione el ID de administrador con el ID de usuario de RACF. El ID de usuario de RACF está asociado con el administrador definido en la estación de trabajo Tivoli. Por ello se puede rastrear cualquier acción administrativa hasta el usuario que emite la solicitud. 4. Defina un perfil en la clase de recurso TMEADMIN proporcionada por Tivoli para cada administrador que pueda acceder a Dynamic Workload Console. Nota: En las tareas siguientes, que se utilizan para correlacionar los ID de administrador con los ID de usuario de RACF, se recomienda que cada administrador se correlacione con un ID de usuario de RACF exclusivo. 5. Active la clase TMEADMIN especificando el mandato siguiente: SETROPTS CLASSACT (TMEADMIN). 6. En la clase TMEADMIN, utilice la serie siguiente para definir un ID de usuario de RACF exclusivo para cada administrador de Tivoli que realizará operaciones de Dynamic Workload Console: id_usuario@nombrehost. Por ejemplo, para un usuario con el identificador SCOT en el host pelican, utilizaría SCOT@pelican. 7. Especifique el mandato siguiente para definir un perfil de recurso general en la clase TMEADMIN para asociar el administrador con un ID de usuario de RACF (en este ejemplo, SCOT): RDEFINE TMEADMIN SCOT@hostname APPLDATA(’SCOT’) Nota: La serie SCOT@nombrehost no distingue entre mayúsculas y minúsculas. 8. Renueve la clase TMEADMIN con el mandato siguiente: SETROPTS RACLIST(TMEADMIN) REFRESH Si tiene problemas al utilizar caracteres especiales para definir un perfil en la clase TMEADMIN, utilice en su lugar el mandato siguiente: SETROPTS GENERIC(TMEADMIN) REFRESH Además, utilice el signo % en lugar del carácter especial. Por ejemplo, para la página de códigos del italiano, RACF no acepta el carácter @ (hex'B5'). Por lo tanto, para SCOT@pelican, debe especificar SCOT%pelican. Capítulo 3. Implementación de seguridad 207 Control del acceso utilizando Dynamic Workload Console Al buscar en una lista de archivos TMEADMIN una coincidencia, RACF busca el perfil genérico más similar. Utilización de un nuevo parámetro de inicialización de servidor para asociar un ID de usuario de RACF Defina un miembro en el archivo identificado por la sentencia EQQPARM DD en el trabajo de inicio del servidor. Este miembro contiene todas las asociaciones entre un usuario de controlador z/OS y un identificador de usuario de RACF. 1. Establezca el parámetro USERMAP en el parámetro de inicialización del servidor SERVOPTS para definir el nombre de usuario, de la forma siguiente: SERVOPTS SUBSYS(xxxx) USERMAP(USERS) PROTOCOL(E2E) PORTNUMBER(425) 2. Utilizando el mismo enfoque que para la clase TMEADMIN, compruebe que el miembro USERS del conjunto de datos del parámetro de inicialización contenga lo siguiente: USER ’SCOT@PELICAN’ RACFUSER(SCOT) RACFGROUP(GROUP1) USER ’PAOLO@PELICAN’ RACFUSER(FALSI) RACFGROUP(GROUP1) USER ’MOSSOTT@PELICAN2’ RACFUSER(FMOSSOTT) RACFGROUP(GROUP1) En la tabla siguiente se muestra la relación entre productos de seguridad y las selecciones de seguridad. Tabla 24. Relación entre productos de seguridad y selecciones de seguridad Producto de seguridad utilizado Solución Requisito previo Security Server (RACF) TMEADMIN Ninguno (clase TMEADMIN proporcionada en z/OS base) Otro que cumpla el estándar de SAF TMEADMIN Definir manualmente la clase TMEADMIN (utilizando los ejemplos EQQ9RFDE y EQQ9RF01) Todos los productos de seguridad Tabla de correlación de ID Cómo permitir acceso al controlador mediante Dynamic Workload Console Si utiliza Dynamic Workload Console, puede controlar el acceso a controlador mediante las funciones de seguridad del conector z/OS y Tivoli Workload Scheduler for z/OS. Asegúrese de tener en cuenta estos dos entornos cuando actualice RACF. ID de usuario implicados en Dynamic Workload Console En el ejemplo siguiente se describe cómo el ID de administrador de Tivoli y el ID de usuario local están relacionados y cómo se utilizan mediante Dynamic Workload Console: v El nombre del host en el que se ejecuta Dynamic Workload Console es Rome1 v v v v Un administrador denominado ADMN1 está definido en Rome1 Un usuario local LOCUSR1 está definido en Rome1 El administrador ADMN1 está asociado con el usuario local LOCUSR1 controlador identifica Dynamic Workload Console mediante este nombre de usuario: USER ADMN1-AT-ROME1-domain RACFUSER (TSOuser) 208 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Control del acceso utilizando Dynamic Workload Console donde TSOuser es el ID de usuario de TSO con el que se ejecuta los diálogo de Tivoli Workload Scheduler for z/OS. Identidad de usuario de WebSphere Application Server: Cuando el conector z/OS abre una conexión al servidor de Tivoli Workload Scheduler for z/OS, WebSphere Application Server autentica la comunicación por medio de la identidad de usuario de WebSphere Application Server. En función de la configuración, la identidad de usuario del servidor puede ser una de las siguientes: v Una identidad de servidor generada automáticamente que no está almacenada en un repositorio de usuarios (por ejemplo SERVER:TIPCELL_TIPNODE_SERVER1). v Una identidad de servidor que está almacenada en el repositorio. En cualquiera de los casos tiene que asociar la identidad de usuario del servidor a un ID de RACF. Puede modificar la configuración para utilizar el ID de administrador como la identidad de usuario del servidor editando la herramienta changeSecurityproperty de WebSphere Application Server (TWA_home/wastools o TWA_home\wastools) donde puede establecer UseRegistryServerId=true y especificar el ID de usuario y la contraseña del administrador en las claves ServerID y ServerPassword. Control del acceso mediante mandatos TSO Puede utilizar los mandatos TSO de IBM Tivoli Workload Scheduler for z/OS para realizar diversas funciones. En la Tabla 25 se muestran los mandatos y los recursos a los que éstas necesitan acceder. Tabla 25. Requisitos del acceso para los mandatos TSO de IBM Tivoli Workload Scheduler for z/OS Mandato Recurso fijo Subrecurso Descripción BACKUP BKP Inicia la copia de seguridad de un conjunto de datos de IBM Tivoli Workload Scheduler for z/OS BULKDISC BUL Inicia el descubrimiento masivo del agente de supervisión JSUACT JSUB Activa o desactiva el envío de trabajos OPINFO CP Actualiza el campo de usuario de una operación OPSTAT RL RL.WSNAME Cambia el estado de una operación SRSTAT SR SR.SRNAME Crea o actualiza un recurso especial WSSTAT RL RL.WSSTAT Cambia el estado de una estación de trabajo La autorización del solicitante la verifica el nombre del subsistema identificado en el mandato, si hay definida una sentencia AUTHDEF para ese subsistema. Si se realiza la difusión de la solicitud, cada subsistema IBM Tivoli Workload Scheduler for z/OS del sistema z/OS al que se dirige el mandato intentará verificar la autorización del solicitante antes de generar un suceso. Podría ser rechazado por un subsistema y aceptado por otro. Un usuario debe tener autorización de actualización en el recurso necesario para utilizar mandatos TSO. Managing the Workload describe detalladamente los mandatos TSO. Capítulo 3. Implementación de seguridad 209 Funciones y datos que puede proteger Funciones y datos que puede proteger Puede utilizar recursos fijos y subrecursos para proteger las funciones y datos de Tivoli Workload Scheduler for z/OS. Los recursos fijos siempre se comprueban como parte del diálogo de Tivoli Workload Scheduler for z/OS. Los subrecursos se comprueban sólo si están definidos en la sentencia AUTHDEF. En la Tabla 26 se describen todos los recursos fijos y subrecursos. Utilice la tabla para determinar los recursos que debe definir en RACF. Utilice la Tabla 27 en la página 215 para determinar el acceso que es necesario a los recursos definidos para cada usuario. Nota: El nombre del subrecurso y el nombre del recurso RACF no coinciden. Debe especificar el nombre de subrecurso que se muestra en la columna 2 en la palabra clave SUBRESOURCES de AUTHDEF para iniciar la verificación del subrecurso. El nombre del recurso de RACF correspondiente que se muestra en la columna 3 se debe definir en la clase de recurso general utilizada por Tivoli Workload Scheduler for z/OS, que se especifica en la palabra clave CLASS de AUTHDEF. | Tabla 26. Recursos fijos y subrecursos protegidos | | Recurso fijo | | | | | | | | | | | AD | ADEP | | CL | | | | | | | | | | | | CP | | | ETT | HIST Subrecurso AD.ADNAME AD.ADGDDEF AD.NAME AD.OWNER AD.GROUP AD.JOBNAME AD.SECELEM AD.UFVAL CL.CALNAME CP.ADNAME CP.CPGDDEF CP.NAME CP.OWNER CP.GROUP CP.JOBNAME CP.WSNAME CP.ZWSOPER CP.SECELEM CP.UFVAL ET.ETNAME ET.ADNAME 210 Nombre de recurso de RACF Descripción AD ADA.nombre ADD.nombre ADN.nombre ADO.nombre ADG.nombre ADJ.nombre ADM.NAME ADU.nombre_campo. valor_campo Archivo de descripción de la aplicación Nombre de la aplicación Nombre de ID de definición de grupos Nombre ampliado de la operación en la descripción de la aplicación ID de propietario ID de grupo de autorización Nombre de trabajo de operación en descripción de la aplicación Nombre de elemento de seguridad Nombre y valor de campo de usuario. ADEP Selección de todas las dependencias en el diálogo QCP CL CLC.nombre Datos de calendario Nombre de calendario CP CPA.nombre CPD.nombre CPN.nombre CPO.nombre CPG.nombre CPJ.nombre CPW.nombre CPZ.nombre CPM nombre CPU.nombre_campo. valor_campo Archivo de plan actual Nombre de aparición ID de definición de grupo de apariciones Nombre ampliado de la operación ID de propietario de la aparición ID de grupo de autorización de la aparición Nombre de la operación de la aparición Nombre de la estación de trabajo del plan actual Nombre de la estación de trabajo utilizado por una operación Nombre de elemento de seguridad Nombre y valor de campo de usuario de operación. ETT ETE.nombre ETA.nombre Diálogo ETT Nombre del suceso desencadenante Nombre de aplicación que se añadirá HIST Recuperación de datos de historial con el mandato HIST IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Funciones y datos que puede proteger | Tabla 26. Recursos fijos y subrecursos protegidos (continuación) | | Recurso fijo | | | | JL | | | | | | JS | | | | JV | | | | LT | | OI | | PR | | | | | | | RL | | RD | | | | | | | | | | | | | RP | | SR | | | WS | ARC Subrecurso Nombre de recurso de RACF JLD.NAME JLM.NAME JL JLD.name JLM.name Conjuntos de datos de bibliotecas de trabajos Nombre de conjunto de datos de bibliotecas de trabajos Nombre de miembro JCL JS.ADNAME JS.OWNER JS.GROUP JS.JOBNAME JS.WSNAME JS JSA.nombre JSO.nombre JSG.nombre JSJ.nombre JSW.nombre Archivo de biblioteca de trabajos y JCL Nombre de aparición ID de propietario de la aparición ID de grupo de autorización de la aparición Nombre de la operación de la aparición Nombre de la estación de trabajo del plan actual JV.OWNER JV.TABNAME JV JVO.nombre JVT.nombre Archivo de definición de variables de JCL ID de propietario de la tabla de definición de variables de JCL Nombre de tabla de variables de JCL LT.ADNAME LT.LTGDDEF LT.OWNER LT LTA.nombre LTD.nombre LTO.nombre Archivo de plan a largo plazo Nombre de aparición ID de definición de grupo de apariciones ID de propietario de la aparición OI.ADNAME OI OIA.nombre Archivo de instrucciones del operador Nombre de la aplicación PR.PERNAME PR PRP.nombre Datos del periodo Nombre del periodo RL.ADNAME RL.OWNER RL.GROUP RL.WSNAME RL.WSSTAT RL RLA.nombre RLO.nombre RLG.nombre RLW.nombre RLX.nombre Datos de la lista de preparados Nombre de aparición ID de propietario de la aparición ID de grupo de autorización de la aparición Nombre de estación de trabajo de planes actuales Estación de trabajo de plan actual modificada por WSSTAT RD.RDNAME RD RDR.nombre Archivo de recursos especiales Nombre de recurso especial RP.REPTYPE RP RPT.tipo_rep Informes de Dynamic Workload Console Tipo de informe en función del informe que solicite: RUNHIST Para informes de historial de ejecución del trabajo. RUNSTATS Para estadísticas de ejecución del trabajo. WWR Para informes de tiempos de ejecución de carga de trabajo de la estación de trabajo. WWS Para resumen de carga de trabajo de la estación de trabajo. SQL Para informes obtenidos por consultas SQL personalizadas. SR.SRNAME SR SRS.nombre Recursos especiales en el plan actual Nombre de recurso especial WS.WSNAME WS WSW.nombre Datos de la estación de trabajo Nombre de la estación de trabajo en la base de datos de estaciones de trabajo ARC Activa/desactiva la recuperación automática Descripción Capítulo 3. Implementación de seguridad 211 Funciones y datos que puede proteger | Tabla 26. Recursos fijos y subrecursos protegidos (continuación) | | Recurso fijo | | BKP BKP Solicita copia de seguridad de un conjunto de datos de recurso | | BUL BUL Inicia el descubrimiento masivo del agente de supervisión | | CMAC CMAC Limpieza de conjuntos de datos y catálogos utilizada por la función de reinicio y limpieza. | CONT CONT Renueva los subrecursos de RACF | | ETAC ETAC Activa/desactiva el seguimiento desencadenado por sucesos | EXEC EXEC Mandato EX (ejecutar) fila | JSUB JSUB Activa/desactiva el envío del trabajo | REFR REFR Renueva LTP y suprime CP | | WSCL WSCL Datos de todas las estaciones de trabajo cerradas Subrecurso Nombre de recurso de RACF Descripción Como se muestra en la Tabla 26, estos elementos existen sólo como recursos fijos: 212 Nombre Protege ADEP El uso de la consulta ALL DEP desde el panel EQQSOPGD en el diálogo Consulta del plan actual (QCP). Para utilizar esta función, debe tener autorización de lectura o actualización en el recurso fijo ADEP. ARC Función ACTIVAR/DESACTIVAR recuperación automática del diálogo Funciones de servicio de Tivoli Workload Scheduler for z/OS. Para utilizar esta función, debe tener autorización de actualización en el recurso fijo ARC. BKP Uso del mandato BACKUP. BACKUP permite solicitar una copia de seguridad del conjunto de datos del plan actual o conjunto de datos del repositorio de JCL. Para utilizar este mandato, debe tener acceso de actualización en el recurso fijo BKP en el sistema donde se emite el mandato. BUL Uso del mandato BULKDISC. BULKDISC permite iniciar un descubrimiento masivo. Para utilizar este mandato, debe tener acceso de actualización en el recurso fijo BUL en el sistema donde se emite el mandato. CMAC Función de reinicio de limpieza en los paneles de Tivoli Workload Scheduler for z/OS. Para utilizar Reinicio de paso, Reinicio de trabajo e Iniciar limpieza debe tener autorización de actualización en el recurso fijo CMAC. No es necesaria ninguna autorización a CMAC para utilizar Visualizar limpieza. CONT La función RECURSOS DE RACF del diálogo Funciones de servicio de Tivoli Workload Scheduler for z/OS. Esto permite activar subrecursos definidos después del inicio de Tivoli Workload Scheduler for z/OS. Para utilizar esta función, debe tener autorización de actualización en el recurso fijo CONT. ETAC La función ACTIVAR/DESACTIVAR ETT del diálogo Funciones IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Funciones y datos que puede proteger de servicio. Para utilizar esta función, debe tener autorización de actualización en el recurso fijo ETAC. EXEC Uso del mandato EX (ejecutar) fila. Puede emitir este mandato en el diálogo Modificar plan actual y listas de preparados de la estación de trabajo, si tiene acceso de actualización al recurso fijo EXEC. JSUB La función ACTIVAR/DESACTIVAR envío de trabajo del diálogo Funciones de servicio de Tivoli Workload Scheduler for z/OS o el mandato TSO JSUACT. Para utilizar esta función, debe tener autorización de actualización al recurso fijo JSUB. REFR La función RENOVAR (Suprimir plan actual y restablecer plan a largo plazo) del diálogo Funciones de servicio de Tivoli Workload Scheduler for z/OS. Para utilizar esta función, debe tener autorización de actualización en el recurso fijo REFR. WSCL La función Todas las estaciones de trabajo cerradas del diálogo Descripción de la estación de trabajo. Para examinar la lista de intervalos de tiempo cuando todas las estaciones de trabajo están cerradas, debe tener autorización de lectura en el recurso fijo de WSCL. Para actualizar la lista, debe tener autorización de actualización en el recurso fijo de WSCL. Atención: Asegúrese de restringir el acceso a estos recursos fijos a los usuarios que los necesitan. REFR es especialmente importante ya que esta función suprime el plan actual. Notas sobre los recursos fijos y subrecursos: 1. Los subrecursos AD.JOBNAME y CP.JOBNAME protegen sólo el campo JOBNAME dentro de una aplicación o aparición. Debe utilizar estos subrecursos para limitar los nombres de trabajos a los que el usuario puede acceder durante la configuración del trabajo y tareas similares. Si no utiliza estos subrecursos, es posible que un usuario del diálogo obtenga mayor autorización utilizando Tivoli Workload Scheduler for z/OS para realizar determinadas funciones. Por ejemplo, un usuario podría enviar un trabajo no autorizado añadiendo una aplicación al plan actual, cambiando el nombre del trabajo y, a continuación, permitiendo a Tivoli Workload Scheduler for z/OS enviar el trabajo. Para estos subrecursos, sólo es significativo el nivel ACCESS(UPDATE). 2. Los subrecursos AD.GROUP, CP.GROUP, JS.GROUP y RL.GROUP se utilizan para proteger el acceso a los datos de Tivoli Workload Scheduler for z/OS en función del ID de autorización y no de los grupos de descripciones de aplicaciones. 3. Los datos del subrecurso se pasan a SAF sin modificaciones. Es posible que el producto de seguridad tenga restricciones sobre los caracteres que permite. Por ejemplo, los nombres de recursos de RACF no pueden contener asteriscos, espacios en blanco incorporados o caracteres DBCS. 4. El miembro EQQ9RFDE de la biblioteca de ejemplos actualiza las tablas de descriptor de clase con un clase específica de Tivoli Workload Scheduler for z/OS denominada OPCCLASS. 5. Utilice el subrecurso CP.ZWSOPER si desea proteger una operación en función del nombre de la estación de trabajo donde se iniciará la operación. Debe tener acceso de actualización a este subrecurso si desea modificar una operación. Si desea especificar dependencias entre las operaciones, debe tener autorización de actualización a la operación predecesora y sucesiva. Capítulo 3. Implementación de seguridad 213 Funciones y datos que puede proteger Puede utilizar el subrecurso CP.ZWSOPER para obtener protección frente a actualizaciones de una operación en una aparición o la supresión o adición no autorizada de una operación en una aparición. Este subrecurso no se utiliza para proteger la adición de una aparición en el plan actual o para proteger una aparición en el plan actual que un usuario intenta suprimir, establecer en espera o establecer en completada. Cuando se vuelve a ejecutar una aparición, se comprueba la autorización de acceso sólo para la operación específica desde la que se ha iniciado la reejecución. El subrecurso CP.ZWSOPER es distinto del subrecurso CP.WSNAME, que protege las estaciones de trabajo pero no protege frente a actualizaciones de las operaciones. 6. Cuando no hay disponible información de apariciones del plan actual, la protección del subrecurso para tareas de edición de JCL y configuración de trabajos se basa en información de la descripción de la aplicación. Por ejemplo, si añade una aparición al CP y solicita edición de JCL para una operación, las solicitudes de subrecursos que utilizan el ID de propietario y el ID de grupo de autorización se emiten utilizando el ID de propietario o ID de grupo de autorización definido en el AD, ya que la aparición de CP no existe. De forma similar, al editar JCL en el diálogo LTP, los subrecursos se basan en la información de apariciones de CP, si la aparición se produce en el CP. Si la aparición no está en el CP, las solicitudes de recurso se emiten utilizando la información del AD. 7. El uso del mandato HIST (historial) desde los paneles de Tivoli Workload Scheduler for z/OS, se necesita al menos un acceso de lectura en el recurso fijo de HIST. 8. No se ejecutan comprobaciones de seguridad en los campos de usuario para los que no haya ningún valor especificado. 9. Subrecursos AD.UFVAL y CP.UFVAL: v Los subrecursos AD.UFVAL y CP.UFVAL se utilizan para proteger los nombres y valores de campo del usuario. Si especifica estos subrecursos en una sentencia AUTHDEF mediante la clase predefinida, IBMOPC, recuerde que el perfil IBMOPC admite los campos de usuario de no más de 54 caracteres. Los 54 caracteres es la suma de los caracteres que componen la serie siguiente: – Para el subrecurso AD.UFVAL: ADU.<nombre_campo>.<valor_campo> | | | | | | | | | | | – Para el subrecurso CP.UFVAL: CPU.<nombre_campo>.<valor_campo> Por lo tanto, si requiere protección para los campos de usuario de más de 54 caracteres, debe crear manualmente un nuevo perfil de RACF o utilizar uno existente que haya definido, que admita los campos de usuario con valores de más de 54 caracteres. Por ejemplo, el perfil podría especificar MAXLNTH=80 para asegurarse de que se admiten valores y nombres de campo de usuario de mayor longitud. v Los caracteres permitidos en las series ADU.<nombre_campo>.<valor_campo> y CPU.<nombre_campo>.<valor_campodependen del producto de seguridad que utilice mediante SAF (System Authorization Facility). El producto de seguridad puede ser RACF o cualquier otro producto que funcione con SAF. No se realizan comprobaciones para validar los caracteres utilizados, de modo que procure no utilizar los caracteres que puedan causar resultados inesperados. Por ejemplo, evite utilizar caracteres que se consideran comodín para el producto de seguridad que esté utilizando. En el caso de RACF, esto significa que evite utilizar los siguientes caracteres comodín: [*, %]. | | | | | | | | | | | | | | | 214 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Requisitos de acceso a recursos fijos Requisitos de acceso a recursos fijos para usuarios de diálogos Para utilizar un diálogo de Tivoli Workload Scheduler for z/OS, debe tener autorización para acceder a los recursos necesarios. En la tabla Tabla 27 se muestra el acceso a recursos que necesita para cada función de diálogo. Por ejemplo, para permitir que el usuario CASHIER añada aplicaciones al plan actual, debe hacer lo siguiente: 1. Busque el diálogo Modificar plan actual (MCP) en la tabla. 2. Busque el botón de añadir. 3. Proporcione al usuario CASHIER acceso a los recursos fijos que se muestran para MPC: acceso de adición/lectura a los perfiles de AD y JS y acceso de actualización al perfil de CP. No es necesario acceso a los demás recursos que se muestran para añadir de MCP, a menos que CASHIER necesite también utilizar las funciones que protegen al añadir una aplicación. Un sufijo numérico identifica la nota que describe la función. Las notas se listan después de la tabla. Si utiliza subrecursos, el usuario debe tener además acceso al subrecurso del que el propietario el recurso fijo. Tabla 27. Requisitos de acceso a recursos fijos para usuarios de diálogos Diálogo Función Recurso fijo Tipo de acceso Estación de trabajo Examinar estación de trabajo WS Lectura Actualizar estación de trabajo WS WSCL Actualización Lectura 1 Examinar estación de trabajo cerrada WSCL Lectura Actualizar estación de trabajo cerrada WSCL Actualización Imprimir Ninguno Ninguno Calendario Examinar CL Lectura Actualización CL Actualización Imprimir Ninguno Ninguno Periodo Examinar PR Lectura Actualización PR JV Actualización Lectura 2 Imprimir CL Lectura Capítulo 3. Implementación de seguridad 215 Requisitos de acceso a recursos fijos Tabla 27. Requisitos de acceso a recursos fijos para usuarios de diálogos (continuación) Diálogo Función Recurso fijo Tipo de acceso Descripción de la aplicación Examinar AD CL WS Lectura Lectura Lectura Lectura Lectura OI RD Actualización AD CL PR WS OI 3 13 Actualización Lectura Lectura Lectura Actualización Lectura 2 Lectura 14 4 JV RD WS Lectura Actualización masiva AD CL PR WS Actualización Lectura Lectura Lectura Lectura Lectura 14 JV RD Instrucciones del operador 5 Imprimir Examinar OI Lectura Actualización OI Actualización Imprimir Ninguno Ninguno Actualización masiva Ninguno Ninguno Examinar RD WS Lectura Lectura Actualización RD WS Actualización Lectura Seguimiento desencadenado por sucesos Examinar ETT Lectura Actualización ETT Actualización Descripciones de trabajo Examinar AD WS Lectura Lectura Lectura Lectura Recurso especial OI RD Actualización AD CL PR WS OI 3 13 Actualización Lectura Lectura Lectura Actualización Lectura 2 Lectura 14 JV RD Imprimir 216 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste WS Lectura 5 4 Requisitos de acceso a recursos fijos Tabla 27. Requisitos de acceso a recursos fijos para usuarios de diálogos (continuación) | Diálogo Función Recurso fijo Tipo de acceso Tablas de variables de JCL Examinar JV Lectura Actualización JV Actualización Imprimir JV Lectura Examinar JL Lectura Actualización JL Actualización Examinar LT AD CL PR WS Lectura Lectura Lectura Lectura Lectura Actualizar (suprimir o modificar) o añadir LT AD CL PR WS JV Actualización Lectura Lectura Lectura Lectura Lectura 2 Configuración de trabajos LT AD CL PR WS JS Lectura Lectura Lectura Lectura Lectura Actualización Proceso por lotes LT Lectura Visualizar estado LT Lectura Establecer valores predeterminados Ninguno Ninguno Planificación diaria Proceso por lotes CP Lectura Comunicación de la estación de trabajo Utilización de listas de preparados RL CPJS OI JCL en biblioteca de trabajos Plano a largo plazo JV EXEC Lista de espera Actualización Lectura 7 Actualización Lectura 9 Lectura 10 Actualización CPJS OI Lectura Actualización Lectura 9 Configuración de trabajos CPJS OI Lectura Actualización Lectura 9 Revisar estado de estaciones de trabajo CP Lectura Definir listas de preparados Ninguno Ninguno 6 8 12 8 Capítulo 3. Implementación de seguridad 217 Requisitos de acceso a recursos fijos Tabla 27. Requisitos de acceso a recursos fijos para usuarios de diálogos (continuación) Diálogo Función Recurso fijo Tipo de acceso Modificar plan actual (MCP) Adición AD CPJS JV SR Lectura Actualización Lectura Lectura 2 Actualización Actualizar (suprimir o modificar), cambiar estado de estaciones de trabajo CPJS JV SR Cambiar estado, reejecutar, manejo CPJS de errores OI EXEC Funciones de servicio Notas: 1. Si 2. Si 3. Si 4. Si 5. Si 6. Si 7. Si 8. Si 9. Si 218 Actualización Actualización Lectura 9 Actualización Reinicio y limpieza CPJS CMAC Actualización Actualización Actualización Examinar CPJS OI SR Lectura Lectura Lectura Lectura Configuración de trabajos Consulta del plan actual (QCP) Actualización Actualización Lectura 2 Actualización CPJS 8 15 8 12 11 9 13 Lectura Actualización Definir lista de errores Ninguno Ninguno Solicitud de datos de historial HIST lectura16 Todo CPJS OI SR Lectura Lectura Lectura Lectura 11 9 13 Activar/desactivar envío de trabajos JSUB CP Actualización Actualización Activa/desactiva la recuperación automática ARC CP Actualización Actualización Renovar (suprimir plan actual y restablecer plan a largo plazo) REFR LT Actualización Actualización Activar recursos RACF CONT Actualización Activa/desactiva el seguimiento desencadenado por sucesos ETAC Actualización Producir cinta APAR Ninguno Ninguno modifica los intervalos abiertos para un día especifica o actualiza un nombre de tabla de variables de JCL examina las instrucciones del operador modifica las instrucciones del operador ha ordenado según el orden de las estaciones de trabajo desea cambiar el estado solicita una revisión de los detalles desea modificar JCL desea examinar las instrucciones del operador IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste 15 8 Requisitos de acceso a recursos fijos 10. Si realiza configuración de trabajos utilizando la sustitución de variables de JCL 11. Si desea examinar el JCL 12. Si desea emitir el mandato EX (ejecutar) 13. Si desea examinar los recursos especiales 14. Si desea especificar asignaciones de los recursos especiales 15. Si desea añadir o actualizar recursos especiales 16. Para emitir el mandato HIST (historial), al menos necesita tener acceso de lectura. Ejemplos de estrategias de seguridad Puede implementar seguridad en Tivoli Workload Scheduler for z/OS de muchas formas. En esta sección se muestran dos ejemplos extremos: v Una estrategia centralizada en la que todas las funciones de seguridad se controlan en un sitio central utilizando recursos fijos v Una estrategia descentralizada en la que la mayoría de las funciones de seguridad se delegan a los usuarios finales y se definen muchos subrecursos. La estrategia de seguridad probablemente se encuentra en algún punto entre estos dos extremos. Estrategia de seguridad centralizada Todos los usuarios de Tivoli Workload Scheduler for z/OS se reúnen en una sola área. Tienen como mínimo conocimientos prácticos de todas las funciones principales de Tivoli Workload Scheduler for z/OS. Debido a que comparten las mismas tareas, es poco necesario dividir las autorizaciones. Los únicos usuarios externos a Tivoli Workload Scheduler for z/OS se encuentran en la agrupación de impresoras, donde los operadores notifican el progreso en la lista de preparados para impresión. Los operadores de la sala de máquina no tienen tareas de Tivoli Workload Scheduler for z/OS; las personas en el área de Tivoli Workload Scheduler for z/OS realizan ellas mismas reejecuciones y correcciones de JCL. Se definen los siguientes grupos de RACF: Grupo Contiene OPCGROUP La mayoría de los usuarios de Tivoli Workload Scheduler for z/OS. OPCSPEC El gestor, los dos líderes de grupo, los programadores de sistemas responsables de Tivoli Workload Scheduler for z/OS y sus copias de seguridad. OPCPRINT Los usuarios de la lista de preparados en la agrupación de impresoras. Acceso externo a IBM Tivoli Workload Scheduler for z/OS Se proporciona acceso de actualización a los conjuntos de datos de Tivoli Workload Scheduler for z/OS a OPCSPEC. Esto proporciona acceso fuera de Tivoli Workload Scheduler for z/OS de forma que el gestor y los líderes de grupo pueden enviar trabajos por lotes que causan actualizaciones, como por ejemplo una ampliación de plan diario. Los programadores de sistemas pueden utilizar programas que no sean Tivoli Workload Scheduler for z/OS para extraer información de diagnóstico. Capítulo 3. Implementación de seguridad 219 Estrategia de seguridad centralizada Acceso mediante el subsistema IBM Tivoli Workload Scheduler for z/OS Se definen los siguientes niveles de autorización: 1. Acceso al subsistema: se proporciona a OPCSPEC y OPCGROUP acceso de actualización en la clase APPL, lo que les permite utilizar todas las funciones (recursos fijos) en el diálogo Tivoli Workload Scheduler for z/OS que no están específicamente protegidos. Se proporciona a OPCPRINT acceso de lectura al subsistema Tivoli Workload Scheduler for z/OS en la clase APPL. 2. Funciones críticas: algunos recursos fijos, como por ejemplo JSUB y REFR, representan funciones que afectan gravemente al funcionamiento de Tivoli Workload Scheduler for z/OS, y que se pueden activar o desactivar mediante una única pulsación. El acceso a estas funciones se restringe a OPCSPEC para reducir el riesgo de errores accidentales: RDEFINE (OPCCLASS) ARC UACC(NONE) PERMIT ARC ID(OPCSPEC) ACCESS(UPDATE) CLASS(OPCCLASS) Estos pasos se repiten para ETAC, JSUB y REFR. 3. Datos que se actualizan raramente: algunos datos de Tivoli Workload Scheduler for z/OS se actualizan raramente, por ejemplo, la base de datos de calendario normalmente se actualiza sólo una vez al año, y los datos de la estación de trabajo incluso con menos frecuencia. Estas bases de datos las utilizan la mayoría de funciones de Tivoli Workload Scheduler for z/OS, de forma que es recomendable restringir el acceso de actualización a ellas: RDEFINE (OPCCLASS) CL UACC(READ) PERMIT CL ID(OPCSPEC) ACCESS(UPDATE) CLASS(OPCCLASS) Estos pasos se repiten para PR y WS. 4. Protección de subrecursos: los únicos recursos se definen para la estación de trabajo de impresora. El grupo OPCPRINT ya tiene acceso de lectura a los recursos en la clase APPL. Esto permite a los operadores de la agrupación de impresoras especificar las funciones de Tivoli Workload Scheduler for z/OS y examinar los datos. Deben poder actualizar la lista de preparados en la estación de trabajo de impresora (pero no en las demás estaciones de trabajo): a. Se define el recurso fijo RL, y se proporciona a OPCPRINT, OPCGROUP y OPCSPEC acceso de actualización a él: RDEFINE (OPCCLASS) RL UACC(NONE) PERMIT RL ID(OPCSPEC) ACCESS(UPDATE) CLASS(OPCCLASS) PERMIT RL ID(OPCGROUP) ACCESS(UPDATE) CLASS(OPCCLASS) PERMIT RL ID(OPCPRINT) ACCESS(UPDATE) CLASS(OPCCLASS) Esto permite a los operadores de la agrupación de impresoras entrar en el diálogo Comunicación de la estación de trabajo sin violaciones de autorización. b. Se define el subrecurso RLW.*. Se proporciona acceso de actualización a OPCGROUP; y OPCSPEC a OPCPRINT se proporciona sólo acceso de lectura: RDEFINE (OPCCLASS) RLW.* UACC(NONE) PERMIT RLW.* ID(OPCSPEC) ACCESS(UPDATE) CLASS(OPCCLASS) PERMIT RLW.* ID(OPCGROUP) ACCESS(UPDATE) CLASS(OPCCLASS) PERMIT RLW.* ID(OPCPRINT) ACCESS(READ) CLASS(OPCCLASS) Este pasa a ser el acceso predeterminado para todas las estaciones de trabajo que no se definen explícitamente con definiciones de subrecursos adicionales. c. Finalmente, se define el subrecurso RLW.PRT; PRT es el nombre de la estación de trabajo de Tivoli Workload Scheduler for z/OS. Se proporciona a OPCPRINT acceso de actualización: 220 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Estrategia de seguridad centralizada RDEFINE (OPCCLASS) RLW.PRT UACC(NONE) PERMIT RLW.PRT ID(OPCSPEC) ACCESS(UPDATE) CLASS(OPCCLASS) PERMIT RLW.PRT ID(OPCGROUP) ACCESS(UPDATE) CLASS(OPCCLASS) PERMIT RLW.PRT ID(OPCPRINT) ACCESS(UPDATE) CLASS(OPCCLASS) Los miembros del grupo OPCPRINT ahora pueden examinar los datos en Tivoli Workload Scheduler for z/OS y actualizar la lista de preparados para la agrupación de impresoras. Estrategia de seguridad descentralizada La mayor parte del trabajo de Tivoli Workload Scheduler for z/OS se delega a representantes de los departamentos de usuarios finales. Estos realizan todas las funciones de Tivoli Workload Scheduler for z/OS (incluidas las reejecuciones y correcciones de JCL durante el día), pero sólo para las aplicaciones de su propio departamento. Durante el segundo y el tercer turno, los operadores de la sala de máquinas se ocupan de las reejecuciones y correcciones de JCL para todos los departamentos. Se definen los siguientes grupos de RACF: Grupo Contiene OPCGROUP La mayoría de los usuarios de Tivoli Workload Scheduler for z/OS. A diferencia de los usuarios en una instalación centralizada, estos usuarios trabajan solos y realizan todas las funciones de Tivoli Workload Scheduler for z/OS en un número limitado de aplicaciones. OPCSPEC Planificadores y personal de soporte de sistemas que se ocupan de la continuidad de la ejecución de Tivoli Workload Scheduler for z/OS. OPER Personal que corrige trabajos que finalizan con error durante la noche. La diferencia principal respecto a una instalación centralizada es que la autorización se divide por departamento y no por función de Tivoli Workload Scheduler for z/OS. La ubicación descentralizada se basa principalmente en los subrecursos de Tivoli Workload Scheduler for z/OS para la seguridad. Esto hace que los estándares de denominación adquieran mayor importancia si el número de perfiles se va a mantener al mínimo. El administrador debe decidir los nombres de subrecursos que se deben utilizar. Por ejemplo, el acceso a las aplicaciones podría restringirse según el nombre de trabajo, ID de propietario o ID de grupo de autorización. Las funciones críticas como por ejemplo REFR (renovar) no se deben descentralizar. Acceso externo a IBM Tivoli Workload Scheduler for z/OS Como en la instalación centralizada, se proporciona acceso de actualización a conjuntos de datos de Tivoli Workload Scheduler for z/OS a los miembros del grupo OPCSPEC. Sin embargo, en una instalación descentralizada todos los demás grupos deben tener ACCESS(NONE). Esto impide que los miembros de OPCGROUP u OPER lean datos que pertenezcan a otros usuarios. Con acceso de lectura a los conjuntos de datos de Tivoli Workload Scheduler for z/OS, un usuario podría ejecutar un programa de utilidad fuera del subsistema Tivoli Workload Scheduler for z/OS para mirar datos que pertenecen a otro usuario. Acceso mediante el subsistema IBM Tivoli Workload Scheduler for z/OS Se definen los siguientes niveles de autorización: Capítulo 3. Implementación de seguridad 221 Estrategia de seguridad descentralizada 1. Acceso al subsistema: se proporciona acceso de actualización a todos los grupos al subsistema Tivoli Workload Scheduler for z/OS en la clase APPL. Esto permite a todos los usuarios actualizar la mayoría de funciones de Tivoli Workload Scheduler for z/OS (recursos fijos) para su propio departamento. La especificación de clase APPL es el valor predeterminado si se define un recurso fijo. Otra manera de manejar los recursos fijos es definirlos individualmente y proporcionar acceso de actualización a OPCGROUP y OPCSPEC. Pero el grupo OPER requiere acceso de actualización sólo a CP, JS y RL (para reejecuciones y correcciones de JCL). Podrían tener ACCESS(NONE) a los demás recursos fijos. Esto impediría que entrasen en cualquier diálogo de Tivoli Workload Scheduler for z/OS que no necesitan para su trabajo. 2. Funciones críticas: algunos recursos fijos, como por ejemplo JSUB y REFR, representan funciones que afectan gravemente al funcionamiento de Tivoli Workload Scheduler for z/OS, y que se pueden activar o desactivar mediante una única pulsación. El acceso a estas funciones debe ser descentralizado. Se restringe el acceso a OPCSPEC para reducir el riesgo de errores accidentales: RDEFINE (OPCCLASS) ARC UACC(NONE) PERMIT ARC ID(OPCSPEC) ACCESS(UPDATE) CLASS(OPCCLASS) Estos pasos se repiten para ETAC, JSUB y REFR. 3. Protección de subrecursos: la instalación protege el acceso a las aplicaciones y JCL utilizando subrecursos. Pero la instalación no tiene convenios de denominación coherentes para las aplicaciones. De esta forma, la protección de subrecursos se implementa mediante el ID de propietario y nombre de trabajo, que tienen convenios de denominación coherentes. a. Se especifican los subrecursos siguientes en la sentencia AUTHDEF: AD.JOBNAME LT.OWNER AD.OWNER JS.JOBNAME CP.JOBNAME JS.OWNER CP.OWNER RL.OWNER. Los subrecursos AD.JOBNAME, CP.JOBNAME y JS.JOBNAME se utilizan para impedir que los usuarios especifiquen nombres de trabajos no autorizados al crear una aplicación. De lo contrario, Tivoli Workload Scheduler for z/OS se podría utilizar para enviar un trabajo con un nombre de trabajo al que los usuarios normalmente no tienen acceso. b. Los nombres de recursos de RACF se definen con ACCESS(NONE), de forma que el acceso predeterminado para todos los usuarios a estos recursos es NONE: RDEFINE (OPCCLASS) ADJ.* UACC(NONE) Esto se repite para los nombres de recursos ADO.*, CPJ.*, CPO.*, LTO.*, JSJ.*, JSO.* y RLO.*. c. Cuando se crean perfiles, los miembros de OPCGROUP reciben la autorización para decidir la lista de accesos a sus propios subrecursos. Se proporciona a OPCSPEC acceso de actualización en caso de que sea necesario para el soporte: PERMIT ADO.* ID(OPCSPEC) ACCESS(UPDATE) CLASS(OPCCLASS) Esto se repite para cada subrecurso. d. Se proporciona a OPER acceso a los subrecursos CP.OWNER, CP.JOBNAME, JS.JOBNAME, JS.OWNER y RL.OWNER de forma que los operadores pueden trabajar durante los turnos de noche: 222 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Estrategia de seguridad descentralizada PERMIT PERMIT PERMIT PERMIT PERMIT CPO.* CPJ.* JSJ.* JSO.* RLO.* ID(OPER) ID(OPER) ID(OPER) ID(OPER) ID(OPER) ACCESS(UPDATE) ACCESS(UPDATE) ACCESS(UPDATE) ACCESS(UPDATE) ACCESS(UPDATE) CLASS(OPCCLASS) CLASS(OPCCLASS) CLASS(OPCCLASS) CLASS(OPCCLASS) CLASS(OPCCLASS) Si muchos recursos con nombres similares tienen la misma lista de accesos, los recursos se pueden agrupar en perfiles genéricos con el signo de porcentaje (%). Por ejemplo, los perfiles ADO, CPO, JSO, LTO y RLO se podrían especificar como un solo perfil, %%O.*. Tenga en cuenta que *O.* no es una entidad de RACF válida. Se deben definir muchos nombres de recursos de RACF en la clase de recurso de OPCCLASS para proteger los datos de cada propietario. Cada subrecurso tiene su propio perfil, a menos que algunos subrecursos se puedan agrupar en perfiles genéricos. Por ejemplo, los ID de propietario PAYROLL, PAYROLL-A y PAYROLL-02 se pueden agrupar como PAYROLL*. Es posible que la definición de perfiles parezca mucho trabajo, pero el número de propietarios normalmente es limitado y a menudo puede utilizar perfiles genéricos. Debido a que tiene muchos más nombres de trabajos que ID de propietario, las definiciones genéricas de nombres de trabajos son incluso más importantes. La mayoría de los trabajos se pueden manejar con una pequeña cantidad de perfiles genéricos. Capítulo 3. Implementación de seguridad 223 Estrategia de seguridad descentralizada 224 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Capítulo 4. Salidas de Tivoli Workload Scheduler for z/OS Este capítulo contiene información general de la interfaz de programación y de ayuda asociada. Se describen las salidas que invoca Tivoli Workload Scheduler for z/OS. Sus propios programas pueden utilizar la información que pasan las salidas para realizar diversas funciones. Las salidas con prefijo de nombre EQQUXnnn (donde nnn es un número) se invocan cuando se inicia Tivoli Workload Scheduler for z/OS. Las salidas con prefijo de nombre EQQUXxxx (donde xxx no es un número) no las invoca el planificador. Por ejemplo, el ejemplo EQQDELDS o el programa EQQCLEAN invocan EQQUXCAT (si está presente), mientras que un programa PIF invoca EQQUXPIF durante la actualización de la descripción de la aplicación (INSERT AD o REPLACE AD). Cada salida se carga si existe el módulo de salida, si la salida no se ha inhabilitado y si la salida no ha sido sustituida por otro nombre de salida en la sentencia EXITS. Consulte “EXITS” en la página 62 para ver una descripción detallada de la sentencia EXITS. Se invoca la salida de sustitución de variables de JCL en cualquier configuración de trabajo o envío de trabajo cuando una variable de JCL ha recuperado su valor. Las salidas de recuperación automática e incorporación de JCL se invocan mediante sentencias de JCL de Tivoli Workload Scheduler for z/OS. Ninguna de estas salidas resulta afectada por la sentencia EXITS. La salida EQQDPUE1 la utilizan los trabajos por lotes de planificación diaria y no resulta afectada por la sentencia EXITS. Los trabajos por lotes utilizan la salida si está disponible. Si no se encuentra la salida, se graba un mensaje en el registro de mensajes del trabajo por lotes. Se invocan las salidas utilizando convenios de enlace estándar. Cuando se especifica la salida, el registro 1 apunta a una lista de parámetros. Cada dirección de esta lista apunta a un parámetro que se pasa a la salida. La Tabla 28 contiene información sobre las salidas de Tivoli Workload Scheduler for z/OS. Tabla 28. Salidas de Tivoli Workload Scheduler for z/OS AMODE en entrada RMODE al enlazar Nombre de la salida Cargada por EQQUX000 comprobador de seguimiento y controlador 31 EQQUX001 controlador 31 24 Envío de trabajo EQQUX002 controlador 31 24 Lectura de biblioteca de trabajos EQQUX003 controlador 31 ANY Información de descripción de la aplicación EQQUX004 comprobador de seguimiento 24 24 Filtrado de sucesos EQQUX005 comprobador de seguimiento 24 24 Archivado de SYSOUT de JCC © Copyright IBM Corp. 1991, 2011 Descripción de la salida ANY Inicio/detención de Tivoli Workload Scheduler for z/OS 225 Tabla 28. Salidas de Tivoli Workload Scheduler for z/OS (continuación) AMODE en entrada RMODE al enlazar Nombre de la salida Cargada por Descripción de la salida EQQUX006 comprobador de seguimiento 24 24 Creación de registro de incidencias de JCC EQQUX007 controlador 31 ANY Cambio de estado de la operación EQQUX009 controlador 31 ANY Inicio de la operación EQQUX011 controlador 31 ANY Grabación de registro de seguimiento de trabajos EQQUX013 controlador 31 ANY Prevención de adaptación de trabajos EQQUX014 controlador 24 EQQUXCAT Ejemplo EQQDELDS o programa EQQCLEAN 31 Definido por el usuario Captar directiva en sentencia de JCL de //%OPC 24/31 24 Incorporación de JCL Definido por el usuario Variable de JCL 24/31 24 Sustitución de variables Definido por el usuario Volver a crear parámetro de sentencia de control de AJR 31 ANY Recuperación automática de trabajos EQQDPUE1 Trabajo de planificación diaria 31 ANY Informe de planificación diaria EQQUXPIF PIF 31 ANY Validación de los cambios realizados en AD (INSERT o REPLACE AD) EQQUXGDG Programa EQQCLEAN 31 ANY Resolución EQQCLEAN GDG EQQUXSAZ controlador 31 24 Ajuste de hora del planificador ANY Salida de catálogo EQQDELDS/EQQCLEAN 24 Mandato de automatización del sistema Notas: 1. Todas las salidas se especifican con la autorización de RACF del subsistema Tivoli Workload Scheduler for z/OS. 2. No es recomendable invocar el módulo de interfaz del programa, EQQYCOM, desde salidas tomadas del espacio de direcciones del controlador y si se intenta se producirán resultados impredecibles. Consulte Apéndice C, “Biblioteca de ejemplos (SEQQSAMP)”, en la página 419 y la publicación Diagnosis Guide and Reference para obtener más información sobre el entorno de ejecución de las salidas. En las páginas siguientes se describen las salidas de Tivoli Workload Scheduler for z/OS y se incluye información sobre lo siguiente: v Las condiciones que causan que se invoque la salida v La correlación de cada parámetro (descrita en el formato del lenguaje ensamblador). 226 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Invocación de las salidas de usuario Invocación de las salidas de usuario de Tivoli Workload Scheduler for z/OS Salida de inicio/detención (EQQUX000) Se invoca la salida EQQUX000 en el espacio de direcciones del rastreador y el espacio de direcciones del controlador (en espera y activo). El invocador es la tarea del asignador del subsistema EQQZMAIN, al inicializar el espacio de direcciones y al terminar el proceso en el espacio de direcciones. Salida de envío de trabajo (EQQUX001) La salida EQQUX001 se invoca en el espacio de direcciones del controlador (activo). El invocador es la tarea del analizador de la estación de trabajo, cuando se selecciona una operación preparada para su proceso y el JCL de la operación está disponible. Durante la ejecución de la salida, se impide que las otras tareas en el espacio de direcciones lean y actualicen el plan actual. Cuando se invoca la salida EQQUX001 para añadir un nuevo paso, explora toda la secuencia de JCL para localizar la tarjeta de trabajo. Si no encuentra la tarjeta de trabajo, no añade la nueva línea al JCL. Consulte también la sección Limitación del número de pasos de trabajo de la publicación Tivoli Workload Scheduler for z/OS: Gestión de la carga de trabajo. Salida de lectura de biblioteca de trabajos (EQQUX002) La salida EQQUX002 se invoca en el espacio de direcciones del controlador (activo). Los invocadores son el analizador de la estación de trabajo y las tareas de servicio general, cuando se selecciona una operación preparada para su proceso. Durante la ejecución de la salida, se impide que las otras tareas en el espacio de direcciones lean y actualicen el plan actual. Salida de información de descripción de la aplicación (EQQUX003) Se invoca la salida EQQUX003 en el espacio de direcciones del controlador (activo). Los invocadores son el gestor de sucesos, el analizador de la estación de trabajo, las tareas de servicio general, la recuperación automática y el gestor de modalidad normal. Durante la ejecución de la salida, se impide que las otras tareas en el espacio de direcciones lean y actualicen el plan actual. Salida de filtrado de sucesos (EQQUX004) Se invoca la salida EQQUX004 en el espacio de direcciones del rastreador y en el espacio de direcciones del controlador si el controlador tiene una tarea de grabador de sucesos (EWTRTASK(YES) especificada en la sentencia de inicialización OPCOPTS). El invocador es la tarea del grabador de sucesos. Salida de archivado de SYSOUT (EQQUX005) Se invoca la salida EQQUX005 en el espacio de direcciones del rastreador y en el espacio de direcciones del controlador si el controlador tiene JCC activo (JCCTASK(YES) especificado en la sentencia de inicialización OPCOPTS. El invocador es la comprobación de terminación de trabajo. Capítulo 4. Salidas de Tivoli Workload Scheduler for z/OS 227 Invocación de las salidas de usuario Salida de creación de registro de incidencia (EQQUX006) Se invoca la salida EQQUX006 en el espacio de direcciones del rastreador y en el espacio de direcciones del controlador si el controlador tiene la tarea de JCC activa (JCCTRTASK(YES) especificada en la sentencia de inicialización OPCOPTS). El invocador es la comprobación de terminación de trabajo. Salida de cambio de estado de la operación (EQQUX007) Se invoca la salida EQQUX007 en el espacio de direcciones del controlador (activo). Los invocadores son el gestor de sucesos, el analizador de la estación de trabajo, las tareas de servicio general, la recuperación automática y el gestor de modalidad normal. Durante la ejecución de la salida, se impide que las otras tareas en el espacio de direcciones lean y actualicen el plan actual. Salida de iniciación de la operación (EQQUX009) Se invoca la salida EQQUX009 en el espacio de direcciones del controlador (activo). El invocador es la tarea de direccionador de datos. Salida de grabación de registro de seguimiento de trabajos (EQQUX011) Se invoca la salida EQQUX011 en el espacio de direcciones del controlador (activo). Los invocadores son el gestor de sucesos, el analizador de la estación de trabajo, las tareas de servicio general, la recuperación automática y el gestor de modalidad normal. Durante la ejecución de la salida, es posible que se impida que otras tareas en el espacio de direcciones lean y actualicen el plan actual. Salida de prevención de adaptación de trabajos (EQQUX013) Se invoca la salida EQQUX013 en el espacio de direcciones del controlador. El invocador es la tarea del analizador de la estación de trabajo, cuando se selecciona una operación preparada para su proceso y el JCL de la operación está disponible. Durante la ejecución de la salida, se impide que las otras tareas en el espacio de direcciones lean y actualicen el plan actual. Salida de operación dependiente del tiempo (EQQUX014) Se invoca la salida EQQUX014 en el espacio de direcciones del controlador (activo). El invocador puede ser cualquier tarea del gestor de modalidad normal, servidor general, analizador de estación de trabajo o gestor de sucesos, cuando una operación dependiente del tiempo se establece en estado Preparado en un entorno z/OS. Durante la ejecución de la salida, se impide que las otras tareas en el espacio de direcciones lean y actualicen el plan actual. Salida de incorporación de JCL (en directiva FETCH) Se invoca una salida de incorporación de JCL en el espacio de direcciones del controlador (activo). Los invocadores son la subtarea del analizador de la estación de trabajo y las tareas de servicio general. Durante la ejecución de la salida, se impide que las otras tareas en el espacio de direcciones lean y actualicen el plan actual. 228 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Invocación de las salidas de usuario Salida de sustitución de variables (en la variable de definición de trabajos o JCL) Se invoca una salida de sustitución de variables en el espacio de direcciones del controlador (activo) o durante el proceso de planificación diaria. Los invocadores son: v La subtarea del analizador de la estación de trabajo y las tareas de servicio general, si está enviando un trabajo que contiene la biblioteca de trabajos. v El proceso de análisis de definición de trabajos, si está enviando una definición de trabajo que contiene la biblioteca SCRPTLIB, utilizando el diálogo MCP o ejecutando un trabajo por lotes de planificación diaria. Durante la ejecución de la salida, se impide que las otras tareas en el espacio de direcciones lean y actualicen el plan actual. Salida de recuperación automática de trabajos (en la sentencia RECOVER) Se invoca una salida de recuperación automática de trabajos en el espacio de direcciones del controlador (activo). El invocador es la tarea de recuperación automática. Durante la ejecución de la salida, se impide que las otras tareas en el espacio de direcciones lean y actualicen el plan actual. Salida de informe de planificación diaria (EQQDPUE1) La invoca el programa por lotes EQQDPRPT. Salida de catálogo EQQDELDS/EQQCLEAN (EQQUXCAT) EQQUXCAT la invoca el ejemplo EQQDELDS o el programa EQQCLEAN inmediatamente antes de ejecutar una única acción de limpieza. Salida de resolución de GDG de EQQCLEAN (EQQUXGDG) El programa EQQCLEAN invoca la salida EQQUXGDG inmediatamente antes de ejecutar cualquier acción de sobrescritura de GDG en bloques de control de JES. Validación de descripción de la aplicación (EQQUXPIF) EQQUXPIF es llamado por un programa PIF durante la actualización de la descripción de la aplicación (INSERT AD o REPLACE AD). Salida de entorno de planificación diaria EQQDPX01 La salida del entorno de planificación diaria (EQQDPX01) la invocan los trabajos por lotes de planificación diaria de IBM Tivoli Workload Scheduler for z/OS y se utiliza para establecer o modificar los nombres de entorno de planificación asociados con las operaciones en el plan. Esta salida se puede invocar para todas las operaciones nuevas que no se ejecutan en una estación de trabajo tolerante a errores. La salida es opcional: el proceso por lotes del plan diario intenta cargarla, y cuando la encuentra, la utiliza. La salida se debe utilizar con cuidado ya que podría afectar al rendimiento del sistema. Instalación de la salida El módulo de carga que implementa esta salida se debe enlazar a una biblioteca de AFP autorizado en la concatenación LNKLST o definida mediante la sentencia STEPLIB DD en el procedimiento de JCL de Tivoli Workload Scheduler for z/OS. Capítulo 4. Salidas de Tivoli Workload Scheduler for z/OS 229 Invocación de las salidas de usuario Si el módulo de carga realiza alguna entrada o salida, se debe enlazar con RMODE(24) según las restricciones normales de z/OS. De lo contrario, se puede enlazar con RMODE(ANY). Tivoli Workload Scheduler for z/OS invoca la salida en AMODE 31. El parámetro AMODE especificado cuando se enlazó no tiene ningún efecto. Interfaz a la salida Se invoca esta salida en modalidad de tarea, estado de problema y clave 8 y la tarea de paso de trabajo está autorizada por APF. La tarea activa se ejecuta con la misma autorización de acceso que la tarea de paso de trabajo. La salida debe restaurar este estado antes de volver a al emisor de la llamada. Se pasa el control a la salida utilizando la instrucción BAL. La salida se debe devolver al emisor de la llamada utilizando la dirección y la modalidad de direccionamiento pasadas a éste, normalmente el registro 14. La salida se especifica en AMODE 31 pero se debe cambiar a AMODE 24 antes de realizar cualquier operación de entrada o salida y, a continuación, volver a cambiar a AMODE 31 antes de volver al emisor de la llamada. Cuando se especifica la salida, el registro 1 contiene la dirección de la lista de parámetros. Se utiliza cada una de las direcciones de esta lista para ubicar el valor del parámetro. Los siguientes son los parámetros que se pasan a la salida: Parámetros de EQQDPX01 FUNC ADID OPNUM JOBNAME WSNAME SPECNR SPECBUF WSCHENV MCAUSERF FUNC DS DS DS DS DS DS DS DS DS CL6 CL 16 F CL8 CL4 H A CL 16 A (Tipo de función) (Nombre de la operación actual) (Número de operación) (Nombre del trabajo) (Nombre de la estación de trabajo de la operación) (Número de recursos especiales) (Almacenamiento intermedio de recursos especiales) (Nombre del entorno de planificación) (Campo de usuario) Tipo de función: v 'INIT ' primera llamada v 'TERM ' última llamada v 'CHECK ' comprobar llamada a SCHENV Se invoca la salida durante el inicio del proceso por lotes de DP con tipo de función INIT y durante la finalización del proceso por lotes del DP con tipo de función TERM. Se produce de tal manera que la apertura y el cierre tienen lugar sólo al principio y al final del proceso por lotes de DP (para minimizar afectar al rendimiento). Se invoca la salida con tipo de función CHECK cada vez que se debe comprobar una operación. 230 FUNC Está presente sólo por razones de compatibilidad. ADID Es el número de la aplicación a la que pertenece el trabajo. OPNUM Es el número de operación de la operación que representa este trabajo. JOBNAME Es el nombre del trabajo asociado con la operación. IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Invocación de las salidas de usuario WSNAME Es el nombre de la estación de trabajo donde se ejecutará la operación. SPECNR Es el número de nombres de recursos especiales en SPECBUF. SPECBUF Es una dirección a un almacenamiento intermedio que contiene un número de campos de 64 bytes. El número de campos de 64 bytes del almacenamiento intermedio se indica mediante SPECNR. Los primeros 44 bytes de cada campo contienen el nombre del recurso especial. Los últimos 20 bytes de cada campo están reservados para utilizarlos en el futuro. WSCHENV Es el nombre del entorno de planificación almacenado actualmente en el registro de operación de CP. Este valor puede ser modificado por la salida. MCAUSERF Este campo está reservado para los usuarios. Tivoli Workload Scheduler for z/OS no lo utiliza ni actualiza. Salida de inicio/detención de Tivoli Workload Scheduler for z/OS (EQQUX000) Se invoca EQQUX000 cuando Tivoli Workload Scheduler for z/OS se está iniciando y cuando está finalizando normalmente. Puede utilizar esta salida para asignar recursos cuando Tivoli Workload Scheduler for z/OS se inicia y para liberarlos cuando Tivoli Workload Scheduler for z/OS se detiene. Esto evita las sobrecargas adicionales implicadas en la asignación y, posteriormente, liberación de recursos cada vez que éstos se utilizan. La biblioteca de ejemplos SEQQSAMP creada durante la instalación contiene la salida EQQUX0N, que es un ejemplo de salidas de inicio/detención. Para obtener información sobre esta biblioteca y sus ejemplos, consulte Apéndice C, “Biblioteca de ejemplos (SEQQSAMP)”, en la página 419. Instalación de la salida El módulo de carga que implementa la salida de inicio/detención se debe enlazar a una biblioteca autorizada por APF en la concatenación LNKLST o definida mediante la sentencia STEPLIB DD en el procedimiento de JCL de Tivoli Workload Scheduler for z/OS. Si el módulo de carga realiza alguna operación de entrada o salida, se debe enlazar con RMODE(24) según las restricciones normales de z/OS. O se puede enlazar con RMODE(ANY). Tivoli Workload Scheduler for z/OS invoca la salida en AMODE 31; el parámetro AMODE especificado cuando se enlazó no tiene ningún efecto. Interfaz a la salida Se invoca la salida de inicio/detención en modalidad de tarea, estado de problema y clave 8 y la tarea de paso de trabajo está autorizada por APF. La tarea activa se ejecuta con la misma autorización de acceso que la tarea de paso de trabajo. La salida debe restaurar este estado antes de volver a al emisor de la llamada. Se pasa el control a la salida utilizando la instrucción BAL. La salida se debe devolver al emisor de la llamada utilizando la dirección y la modalidad de direccionamiento pasadas a éste, normalmente el registro 14. Capítulo 4. Salidas de Tivoli Workload Scheduler for z/OS 231 Salida EQQUX000 La salida se especifica en AMODE 31 pero se debe cambiar a AMODE 24 antes de realizar cualquier operación de entrada o salida y, a continuación, volver a cambiar a AMODE 31 antes de volver al emisor de la llamada. Cuando se especifica la salida, el registro 1 contiene la dirección de la lista de parámetros. Se utiliza cada una de las direcciones de esta lista para ubicar el valor del parámetro. Los siguientes son los parámetros que se pasan a la salida: Parámetros de EQQUX000 ACTION DS MCAUSERF DS CL8 A (Acción de inicio/detención) (Campo de usuario) ACTION tiene el valor START cuando se invoca la salida durante el inicio de Tivoli Workload Scheduler for z/OS. MCAUSERF es cero para esta llamada inicial. Normalmente, esta salida realizará funciones de inicialización de salida para la llamada de inicio al iniciar Tivoli Workload Scheduler for z/OS. Si la salida necesita asignar almacenamiento que se utiliza cuando Tivoli Workload Scheduler for z/OS está activo, debe actualizar MCAUSERF para direccionar este almacenamiento. ACTION tiene el valor STOP cuando se invoca la salida durante la terminación de Tivoli Workload Scheduler for z/OS. Normalmente, esta salida realiza funciones de terminación de salida para la llamada a stop al detener Tivoli Workload Scheduler for z/OS. Si se actualiza MCAUSERF mediante una llamada a start, se pasa el mismo valor a la salida para la llamada a stop. Salida de envío de trabajo (EQQUX001) Se invoca EQQUX001 cuando Tivoli Workload Scheduler for z/OS va a enviar un trabajo por lotes o iniciar una tarea iniciada. Puede utilizar esta tarea para hacer lo siguiente: v Modificar la secuencia de JCL, pero no puede aumentar el número de registros de JCL, a menos que utilice la palabra clave OPCOPTS EXIT01SZ. v Modificar el usuario que envía trabajos con scripts centralizados en estaciones de trabajo tolerantes a errores. v Hacer que el mismo usuario sea el propietario del trabajo de limpieza autónomo y del trabajo original. La biblioteca de ejemplos SEQQSAMP creada durante la instalación contiene la salida EQQUX001, que es un ejemplo de salidas de envío de trabajos. Para obtener información sobre esta biblioteca y sus ejemplos, consulte Apéndice C, “Biblioteca de ejemplos (SEQQSAMP)”, en la página 419. Instalación de la salida El módulo de carga que implementa la salida de envío de trabajos se debe enlazar a una biblioteca autorizada por APF en la concatenación LNKLST o a una biblioteca definida por la sentencia STEPLIB DD en el procedimiento de JCL de Tivoli Workload Scheduler for z/OS. El módulo de carga también se debe enlazar con los atributos RMODE(24) y AMODE(31). También se da soporte a AMODE(24), aunque no está recomendado. 232 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Salida EQQUX001 Interfaz a la salida Se invoca la salida de envío de trabajos en modalidad de tarea, estado de problema y clave 8 y la tarea de paso de trabajo está autorizada por APF. La tarea activa se ejecuta con la misma autorización de acceso que la tarea de paso de trabajo. La salida debe restaurar este estado antes de volver a al emisor de la llamada. Tivoli Workload Scheduler for z/OS invoca la salida en la modalidad de direccionamiento definida por el atributo AMODE del módulo de carga. Cuando se invoca la salida en modalidad de direccionamiento de bits, la secuencia de trabajos pasada a la salida se encuentra por encima de la línea de 16M. Cuando se invoca la salida en modalidad de direccionamiento de 24 bits, la secuencia de trabajos que se pasa a la salida se encuentra por encima de la línea de 16M. Se pasa el control a la salida utilizando la instrucción de BASSM. La salida debe volver a al emisor de la llamada utilizando la dirección pasada a éste, normalmente el registro 14. Se puede realizar el retorno de la salida en cualquier modalidad de direccionamiento. Cuando se especifica la salida, el registro 1 contiene la dirección de la lista de parámetros. Se utiliza cada una de las direcciones de esta lista para ubicar el valor del parámetro. Los siguientes son los parámetros que se pasan a la salida: Capítulo 4. Salidas de Tivoli Workload Scheduler for z/OS 233 Salida EQQUX001 Parámetros de EQQUX001 JOBNAME DS CL8 (Nombre del trabajo) JCLLEN DS F (Tamaño, en bytes, de secuencia de trabajos actual) JCLAREA DS n * CL80 (Todos los registros de la secuencia de trabajos) LATEOUT DS CL10 (Último inicio, formato AAMMDDHHMM) ESTDUR DS CL4 (Duración estimada, formato HHMM) NUMPS DS H (Número de servidores paralelos necesarios) NUMR1 DS H (Cantidad necesaria de recurso 1 de estación de trabajo) NUMR2 DS H (Cantidad necesaria de recurso 2 de estación de trabajo) SPECRES DS CL8 (Primeros 8 caracteres de nombre de primer recurso especial) ADID DS CL16 (Nombre de aplicación actual) MCAUSERF DS A (Campo de usuario) GROUP DS CL8 (Nombre de grupo de autorización actual) RUSER DS CL8 (Nombre del usuario de RACF que envía el trabajo) OPERTYPE DS CL1 (J para trabajo JCL, S para tarea iniciada, F para trabajo global centralizado) UPDAT DS C (Y o N, define origen de trabajo) JCLUSER DS CL8 (Último usuario que actualizó este trabajo) JCLUTIME DS CL10 (Hora de última actualización, formato AAMMDDHHMM) OPNUM DS F (Número de operación) IATIME DS CL10 (Hora de entrada de llegada de aparición, AAMMDDHHMM) OWNER DS CL16 (Nombre de propietario de la aplicación) SPECNR DS H (Número de recursos especiales) SPECBUF DS A (Almacenamiento intermedio de recursos especiales) WSNAME DS CL4 (Nombre de la estación de trabajo de la operación) RETCO DS CL4 (Código de error de la operación) NEWREC DS F (Número de líneas de JCL en NEWJCL) NEWJCL DS n*CL80 (Nueva jclarea) USDREC DS F (Número de líneas de JCL utilizadas en NEWJCL) XINFO DS A (Dirección de información ampliada) XJNAMLEN DS F (Longitud de nombre de trabajo ampliado) CALTYP DS C (Tipo de llamada:N si es llamado por WASUB, R si es llamado por WASUJ) NOREEX DS C (Tipo de llamada: N si es la primera llamada, Y si es la segunda u otra siguiente) WSCHENV DS CL 16 (Nombre del entorno de planificación) OCCPTR DS A (Dirección de datos de la aparición) OPRPTR DS A (Dirección de datos de la operación) USRFNR DS F (Número de campos de usuarios) USRFAREA DS A (Dirección de área de campos de usuario) Nota: También se invoca EQQUX001 cuando se vuelve a enviar un trabajo para realizar Reinicio y limpieza. En este caso, los cambios de JCL se ignoran. El área de JCL se pasa a la salida pero no se aplican los cambios. Sólo se procesa la información de ID de usuario y de código de retorno de la salida. 234 JOBNAME Nombre del trabajo que se va a enviar. JCLLEN El tamaño, en bytes, del trabajo. JCLAREA Registro de JCL en el trabajo. LATEOUT El valor de la última hora de inicio que Tivoli Workload Scheduler for z/OS ha calculado para el trabajo. ESTDUR La duración estimada de este trabajo. NUMPS El número de servidores paralelos necesarios. NUMR1 La cantidad de recurso 1 de estación de trabajo necesaria. NUMR2 La cantidad de recurso 2 de estación de trabajo necesaria. IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Salida EQQUX001 SPECRES Los 8 primeros caracteres del nombre de recurso especial. Nota: Cuando se define una operación con más de un recurso especial, el parámetro SPECRES contiene el recurso que es físicamente el primero en el registro ADR del conjunto de datos EQQADDS. Éste es inicialmente el recurso especial definido primero para esta operación, pero puede cambiar en cualquier momento en el que un usuario añada o elimine un recurso especial de la operación. ADID El nombre de la aplicación de la que el trabajo forma parte. MCAUSERF Campo de usuario que también se pasa a la salida EQQUX000. Tivoli Workload Scheduler for z/OS no utiliza ni actualiza el campo MCAUSERF. GROUP Nombre del grupo de autorización al que pertenece la operación actual. RUSER El nombre del usuario de RACF que es propietario del trabajo. Este parámetro contiene 8 espacios en blanco cuando se invoca la salida. La salida puede actualizar este parámetro, si es necesario, para hacer que el trabajo se envíe con el ID de usuario especificado. El valor RUSER devuelto se almacena en el archivo de CP. Garantiza que cada vez que se envíe un trabajo de limpieza autónomo éste tenga el mismo propietario que el trabajo original. Las distintas formas de configurarlo se sugieren en el trabajo de ejemplo EQQUX001 que contiene la biblioteca SEQQSAM. Además, se incluye un ejemplo de código que extrae el valor del parámetro USER de la tarjeta JOB. Consulte los comentarios del ejemplo para obtener más detalles. También puede utilizar este parámetro para modificar el usuario que envía un trabajo con un script centralizado. Si utiliza esta palabra clave para especificar el nombre del usuario que envía el script o mandato especificado en una estación de trabajo tolerante a errores Windows, puede hacer lo siguiente: v Asociar este nombre de usuario a la estación de trabajo Windows en la sentencia de inicialización USRREC. v Establecer LOCALPSW(YES) en la sentencia TOPOLOGY y, a continuación, utilizar el programa de utilidad de usuario para definir el nombre y la contraseña del usuario en el archivo local de la estación de trabajo Windows. Se da soporte a este parámetro incluso si se envía el trabajo a otro sistema mediante un conjunto de datos de envío/liberación. De esta forma, existe una posibilidad de que SUBMIT SUBTASK del controlador o del comprobador de seguimiento que envía un trabajo determinado pueda terminar anormalmente cuando se ejecute con un ID de usuario proporcionado por RUSER en lugar de con el ID de usuario asociado con la tarea iniciada de Tivoli Workload Scheduler for z/OS. Si esto sucediera, es posible que DUMPTASK falle con ABEND913 si el ID de usuario en control no tiene acceso WRITE al conjunto de datos SYSMDUMP. Por este motivo, los conjuntos de datos SYSMDUMP se deben definir con un UACC de UPDATE, es decir, deben ser WRITE-ENABLED para Capítulo 4. Salidas de Tivoli Workload Scheduler for z/OS 235 Salida EQQUX001 todos los ID de usuario con los que es posible que se envíe un trabajo planificado de Tivoli Workload Scheduler for z/OS. Si RUSER está en blanco y la tarjeta de trabajo no especifica la palabra clave USER, el trabajo se envía con la autorización de la tarea iniciada de Tivoli Workload Scheduler for z/OS. 236 OPERTYPE Tiene el valor de J para un trabajo JCL, S para una tarea iniciada, o F para un trabajo global centralizado. UPDAT Tiene el valor Y si el trabajo actual se ha recuperado del conjunto de datos EQQJSnDS. En todos los demás casos, UPDAT tiene el valor N. JCLUSER El nombre del último usuario de TSO que ha actualizado el trabajo actual. Este parámetro es significativo sólo si UPDAT tiene un valor Y. JCLUTIME La fecha y hora de la última actualización del trabajo actual. Este parámetro es significativo sólo si UPDAT tiene un valor Y. OPNUM Número de operación de la operación que representa este trabajo. IATIME Hora de llegada de entrada de la aparición de la aplicación a la que pertenece este trabajo. OWNER Nombre del propietario de la aplicación actual. SPECNR El número de nombres de recursos especiales en SPECBUF. SPECBUF Una dirección a un almacenamiento intermedio que contiene un número de campos de 64 bytes. El número de campos de 64 bytes del almacenamiento intermedio se indica mediante SPECNR. Los primeros 44 bytes de cada campo contienen el nombre del recurso especial. Los últimos 20 bytes de cada campo están reservados para utilizarlos en el futuro. WSNAME Nombre de la estación de trabajo de la operación. RETCO El nombre de un campo que puede utilizar la salida de usuario para detener el envío y establecer el código de error relacionado. Consulte la descripción de la palabra clave SUBFAILACTION en Capítulo 1, “Definición de sentencias de inicialización”, en la página 5 para obtener más detalles. NEWREC El tamaño de la nueva JCLAREA. Se expresa en número de líneas de JCL, cada una de las cuales tiene una longitud de 80 bytes. El valor de JCLAREA lo proporciona a la salida el planificador y no se puede cambiar. Si se utiliza la palabra clave OPCOPTS EXIT01SZ y el valor de NEWREC proporcionado por Tivoli Workload Scheduler for z/OS a la salida es igual a cero, el planificador no tiene almacenamiento suficiente para crear la nueva JCLAREA. NEWJCL El área donde se copia el JCL ampliado. Lo proporciona Tivoli Workload Scheduler for z/OS a la salida para permitir que el tamaño del JCL aumente. USDREC El número de líneas que pertenecen al JCL ampliado que se copian en la nueva jclarea. XINFO La dirección de los datos especificada en el campo de información IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Salida EQQUX001 ampliada del plan actual para la operación correspondiente. Si su valor es 0, no hay disponible ninguna información ampliada en el plan actual. XJNAMLEN La longitud que especifica en el campo Nombre ampliado de la operación del plan actual para la operación correspondiente. Es un subcampo de la información ampliada disponible en el plan actual. WSCHENV El nombre del entorno de planificación almacenado actualmente en el registro de operación de CP. Este valor puede ser modificado por la salida. OCCPTR La dirección de los datos comunes del registro CPLREC3C. OPRPTR La dirección de los datos comunes del registro CPLREC3P. USRFNR El número de registros de campos de usuario en USRFAREA. USRFAREA Dirección del área del campo de usuario. Se distribuye del modo siguiente: USRFAREA USRFNAME DS USRFVAL DS CL16 CL54 (Nombre del campo de usuario) (Valor del campo de usuario) Salida de lectura de biblioteca de trabajos (EQQUX002) Se invoca la salida de lectura de biblioteca de trabajos (EQQUX002) cuando Tivoli Workload Scheduler for z/OS va a recuperar un trabajo por lotes que no existe en el conjunto de datos EQQJSnDS. La salida se utiliza para crear una secuencia de trabajos que Tivoli Workload Scheduler for z/OS enviará a JES. La biblioteca de ejemplos SEQQSAMP creada durante la instalación contiene la salida EQQUX002, que es un ejemplo de salidas de lectura de biblioteca de trabajos. Para obtener información sobre esta biblioteca y sus ejemplos, consulte Apéndice C, “Biblioteca de ejemplos (SEQQSAMP)”, en la página 419. Instalación de la salida El módulo de carga que implementa la salida de lectura de biblioteca de trabajos se debe enlazar a una biblioteca autorizada por APF en la concatenación LNKLST o definida mediante la sentencia STEPLIB DD en el procedimiento de JCL de Tivoli Workload Scheduler for z/OS. El módulo de carga se debe enlazar con RMODE(24) según las restricciones normales de z/OS. Nota: EQQUX002 se debe codificar como REENTRANT si el valor de la palabra clave GSTASK de la sentencia OPCOPTS es mayor que 1. Interfaz a la salida Se invoca la salida de lectura de biblioteca de trabajos en modalidad de tarea, estado de problema y clave 8 y la tarea de paso de trabajo está autorizada por APF. La tarea activa se ejecuta con la misma autorización de acceso que la tarea de paso de trabajo. La salida debe restaurar este estado antes de volver a al emisor de la llamada. Capítulo 4. Salidas de Tivoli Workload Scheduler for z/OS 237 Salida EQQUX002 Se pasa el control a la salida utilizando la instrucción BAL. La salida se debe devolver al emisor de la llamada utilizando la dirección y la modalidad de direccionamiento pasadas a éste, normalmente el registro 14. Si la salida termina anormalmente, se marca como no ejecutable; Tivoli Workload Scheduler for z/OS no intenta invocar de nuevo la salida. Cuando se especifica la salida, el registro 1 contiene la dirección de la lista de parámetros. Se utiliza cada una de las direcciones de esta lista para ubicar el valor del parámetro. Los siguientes son los parámetros que se pasan a la salida: Parámetros de EQQUX002 238 TYPE FUNC JOBNAME IOAREA IOAREAL RETCODE DATAL ERRDATA ADID USRAREA JCLUSER OPNUM IATIME VAROCCP DS DS DS DS DS DS DS DS DS DS DS DS DS DS CL1 CL1 CL8 A F X F CL78 CL16 A CL8 F CL10 A VAROPRP DS A VARWSP DS A MCAUSERF DS A OCCPTR OPRPTR WSPTR AUTHGROU MEMPRO TASKPTR XINFO XJNAMLEN USRFNR USRFAREA DS DS DS DS DS DS DS DS DS DS A A A CL8 CL1 A A F F A (Constante = J) (Constante = G) (Nombre del trabajo) (Dirección del área de E/S) (Tamaño del área de E/S) (Código de retorno) (Cantidad de datos devueltos) (Mensaje de error devuelto) (Nombre de la aplicación actual) (Campo de usuario, 0 en la primera llamada) (Último usuario que actualizó este trabajo) (Número de operación) (Hora de entrada de llegada de aparición, AAMMDDHHMM) (Dirección de datos de la aparición si la operación está en CP) (Dirección de datos de la operación si la operación está en CP) (Dirección de datos de la estación de trabajo si la operación está en CP) (Dirección establecida por el usuario en la salida EQQUX000) (Dirección de datos de la aparición) (Dirección de datos de la operación) (Dirección de datos de la estación de trabajo) (Grupo de autorización) (Indicador de problemas de memoria) (Dirección de TCB de tarea de emisor de la llamada) (Dirección de información ampliada) (Longitud de nombre de trabajo ampliado) (Número de campos de usuario) (Dirección de área de campos de usuario) TYPE Está presente sólo por razones de compatibilidad. FUNC Está presente sólo por razones de compatibilidad. JOBNAME Nombre del trabajo que se va a enviar. IOAREA Dirección de un almacenamiento intermedio asignado por Tivoli Workload Scheduler for z/OS, donde se deben colocar los registros de JCL del trabajo actual. IOAREAL Cantidad de espacio, en bytes, del almacenamiento intermedio de IOAREA RETCODE Lo establece la salida. Son válidos los valores siguientes: 0 Retorno normal. 4 Se ha alcanzado el fin de los datos para el trabajo actual. IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Salida EQQUX002 16 No se ha podido encontrar el trabajo en ningún conjunto de datos de entrada. 20 No hay ningún JCL para que lo devuelva la salida. Tivoli Workload Scheduler for z/OS intenta recuperar el JCL de EQQJBLIB. 44 Espacio insuficiente. La cantidad de espacio libre en el almacenamiento intermedio de IOAREA (como determina IOAREAL) no es suficiente para contener el siguiente bloque de datos. 241 Se ha producido un error de E/S. 242 Se ha producido un error de apertura. No se han podido abrir uno o varios conjuntos de datos. Se invoca de nuevo la salida para continuar procesando el mismo trabajo cuando se devuelve un código de retorno de 0 ó 44. Todos los demás códigos de retorno finalizan el proceso del trabajo actual. DATAL Cantidad de datos devuelta por la salida cuando el código de retorno es 0 ó 4. ERRDATA Área de mensajes del usuario donde puede describir un problema encontrado en la salida. El texto se emite en el mensaje EQQJ576 si la salida establece el código de retorno 242 o en el mensaje EQQJ580 si se establece el código de retorno 241. Nota: Si modifica la entrada de la biblioteca de mensajes para EQQJ576 o EQQJ580 para generar un WTO, debe asegurarse de que no haya más de 70 caracteres de texto de mensaje definidos para cada línea. Reorganice el texto, si es necesario. Además, asegúrese de que el propio ERRDATA no supere los 70 caracteres. ADID Nombre de la aplicación actual. USRAREA Es cero la primera vez que se invoca la salida para recuperar un trabajo. La salida puede establecer este parámetro en cualquier valor. Tivoli Workload Scheduler for z/OS no utiliza ni actualiza este parámetro. La salida debe utilizar el parámetro USRAREA siempre que devuelve un código de retorno de 0 ó 44. Normalmente, el parámetro USRAREA se utiliza para contener la dirección de un área de trabajo en la que la salida ha realizado un GETMAIN. Esta área de trabajo debe contener información suficiente para permitir que la salida continúe procesando el mismo trabajo. JCLUSER Es cero la primera vez que se invoca la salida. La salida debe establecer este parámetro en el nombre del usuario de TSO que se utiliza para la comprobación de autorización cuando el JCL contiene sentencias de recuperación automática. OPNUM Número de operación de la operación que representa este trabajo. IATIME Hora de llegada de entrada de la aparición de la aplicación a la que pertenece este trabajo. Capítulo 4. Salidas de Tivoli Workload Scheduler for z/OS 239 Salida EQQUX002 VAROCCP Dirección de los datos de la aparición. El almacenamiento en esta dirección se correlaciona mediante un segmento CPOC de la interfaz del programa (PIF). VAROPRP Dirección de datos de la operación. El almacenamiento en esta dirección se correlaciona mediante un segmento CPOP de PIF. VARWSP Dirección de datos de la estación de trabajo. El almacenamiento en esta dirección se correlaciona mediante un segmento CPWS de PIF. Nota: VAROCCP, VAROPRP, y VARWSP contienen direcciones válidas sólo si se invoca el texto para operaciones presentes en el plan actual. Las direcciones contienen cero cuando se edita JCL desde el diálogo del plan a largo plazo o cuando se añade una aparición mediante el diálogo MCP. MCAUSERF Campo de usuario que permite asignar recursos en la salida de inicio/detención, EQQUX000, que esta salida puede utilizar posteriormente. Por ejemplo, es posible abrir archivos para la recuperación de JCL en la llamada de tipo start a EQQUX000 en lugar de abrirlos cada vez que se invoca EQQUX002. Tivoli Workload Scheduler for z/OS no utiliza ni actualiza este campo. El campo MCAUSERF es válido cuando el controlador está activo. OCCPTR Dirección de los datos de la aparición. El almacenamiento de esta dirección se correlaciona mediante el segmento CPOC de PIF. OPRPTR Dirección de datos de la operación. El almacenamiento en esta dirección se correlaciona mediante un segmento CPOP de PIF. WSPTR Dirección de datos de la estación de trabajo. El almacenamiento en esta dirección se correlaciona mediante un segmento CPWS de PIF. Nota: OCCPTR, OPRPTR y WSPTR siempre contienen direcciones válidas. Los datos de estas áreas se leen de las bases de datos de descripciones de aplicaciones y descripciones de estaciones de trabajo, si la operación asociada con el JCL no existe en el plan actual. AUTHGROU Nombre del grupo de autorización. MEMPRO Indicador de problemas de memoria. TASKPTR Dirección del bloque de control de tarea de la tarea del emisor de la llamada. Si la salida necesita acceder a sus propios archivos, estos archivos se deben abrir en la primera llamada para un trabajo (valor de USRAREA=0) y cerrar de una de las formas siguientes: v Antes de devolver el control al planificador por última vez (antes de establecer el código de retorno 4) v Cuando se produce un error que no permite que Tivoli Workload Scheduler for z/OS adquiera más memoria, Tivoli Workload Scheduler for z/OS informa a la salida estableciendo mempro en: X'04' Si se alcanza el límite de 608.000 (se ha emitido EQQJ582) X'08' Si no hay suficiente almacenamiento disponible (se ha emitido EQQJ577) XINFO Es la dirección de los datos especificada en el campo de información 240 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Salida EQQUX002 ampliada del plan actual para la operación correspondiente. Si su valor es 0, no hay disponible ninguna información ampliada en el plan actual. XJNAMLEN Es la longitud que especifica en el campo Nombre ampliado de la operación del plan actual para la operación correspondiente. Es un subcampo de la información ampliada disponible en el plan actual. USRFNR El número de registros de campos de usuario en USRFAREA. USRFAREA Dirección del área del campo de usuario. Se distribuye del modo siguiente: USRFAREA USRFNAME DS USRFVAL DS CL16 CL54 (Nombre del campo de usuario) (Valor del campo de usuario) Cuando se invoca la salida EQQUX002 para recuperar un trabajo por primera vez, el área de E/S es de 32.000 bytes. Si la salida ha recuperado todo el trabajo y cabe en el espacio de almacenamiento intermedio disponible, la salida puede actualizar el área de E/S, devolver la cantidad de datos en el trabajo y establecer un código de retorno de 4. Si la salida no ha recuperado todo el trabajo, puede actualizar el área de E/S, devolver la cantidad de datos en el trabajo y establecer un código de retorno de 0 para indicar que hay más datos para devolver. La próxima vez que se invoque la salida, la dirección y el tamaño del área de E/S se actualizarán ya que el área de E/S está siendo parcialmente utilizada por los datos de una llamada anterior. La salida debe continuar este proceso hasta que no haya más datos a devolver y a continuación establecer un código de retorno de 4 para indicar que se ha recuperado todo el trabajo. Debido a que el espacio disponible en el almacenamiento intermedio se reduce para cada llamada, es posible que la salida deba establecer un código de retorno de 44 para indicar que la cantidad de espacio libre no es suficiente. Cuando se devuelve un código de retorno de 44, se invoca de nuevo la salida con un nombre de trabajo de ocho signos de igual (========). Se trata de una llamada de restablecimiento. A continuación, la salida se prepara para procesar el trabajo desde el comienzo. No se pueden devolver datos en la llamada de restablecimiento. Cuando se invoca de nuevo la salida después de la llamada de restablecimiento, el área de E/S es 32.000 mayor que antes. Este proceso de devolver una condición de “espacio insuficiente” se puede repetir hasta 19 veces para un trabajo. Esto significa que el tamaño máximo de almacenamiento intermedio que puede solicitar una salida EQQUX002 es 608.000 bytes. Esto corresponde a un trabajo de 7599 imágenes de tarjeta. Cuando se alcanza un límite de 608.000, Tivoli Workload Scheduler for z/OS emite el mensaje EQQJ582 y se invoca la salida una veinteava vez si MEMPRO se establece en 4. La salida también puede obtener más espacio de almacenamiento intermedio utilizando todo el espacio disponible en el almacenamiento intermedio actual. Cuando esto sucede y se establece un código de retorno de 0, se invoca de nuevo Capítulo 4. Salidas de Tivoli Workload Scheduler for z/OS 241 Salida EQQUX002 la salida con 32.000 bytes libres en el almacenamiento intermedio. La llamada de restablecimiento no se utiliza en este caso; la salida debe continuar procesando el trabajo actual normalmente. La ampliación del almacenamiento intermedio de esta forma puede continuar hasta un tamaño máximo de almacenamiento intermedio de 608.000 bytes. Salida de información de descripción de la aplicación (EQQUX003) Se invoca la salida de información de descripción de la aplicación (EQQUX003) cuando Tivoli Workload Scheduler for z/OS va a actualizar el conjunto de datos de descripción de la aplicación con un nuevo valor para la duración estimada de una operación. La salida puede cambiar el valor de la duración estimada que ha calculado Tivoli Workload Scheduler for z/OS. La biblioteca de ejemplos SEQQSAMP creada durante la instalación contiene la salida EQQUX003, que es un ejemplo de salida de información de descripción de la aplicación. Para obtener información sobre esta biblioteca y sus ejemplos, consulte Apéndice C, “Biblioteca de ejemplos (SEQQSAMP)”, en la página 419. Instalación de la salida El módulo de carga que implementa la salida de información de descripción de la aplicación se debe enlazar a una biblioteca autorizada por APF en el LNKLST definido por la sentencia DD del programa PIF actual. Tivoli Workload Scheduler for z/OS invoca la salida en AMODE 31; el parámetro AMODE especificado cuando se enlazó no tiene ningún efecto. Interfaz a la salida Se invoca la salida de información de descripción de la aplicación en modalidad de tarea, estado de problema y clave 8, y la tarea de paso de trabajo está autorizada por APF. La tarea activa se ejecuta con la misma autorización de acceso que la tarea de paso de trabajo. La salida debe restaurar este estado antes de volver a al emisor de la llamada. Se pasa el control a la salida utilizando la instrucción BAL. La salida se debe devolver al emisor de la llamada utilizando la dirección y la modalidad de direccionamiento pasadas a éste, normalmente el registro 14. La salida se especifica en AMODE 31 pero se debe cambiar a AMODE 24 antes de realizar cualquier operación de entrada o salida y, a continuación, volver a cambiar a AMODE 31 antes de volver al emisor de la llamada. Cuando se especifica la salida, el registro 1 contiene la dirección de la lista de parámetros. Se utiliza cada una de las direcciones de esta lista para ubicar el valor del parámetro. Los siguientes son los parámetros que se pasan a la salida: 242 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Salida EQQUX003 Parámetros de EQQUX003 ADID OPIA OPID DS DS DS CL16 CL10 CL6 OLDDUR CURDUR NEWDUR DS DS DS F F F (Nombre de la aplicación actual) (Llegada de entrada de operación actual, AAMMDDHHMM) (Nombre de estación de trabajo, número de operación (binario)) (Duración estimada anterior, en minutos) (Duración de operación actual, en minutos) (Nueva duración estimada, en minutos) ADID Nombre de la aplicación que se actualizará. OPIA La fecha y hora de llegada de entrada de una operación la describe el registro de descripción de la aplicación actual. OPID Identifica adicionalmente la operación actual proporcionando el nombre de la estación de trabajo y el número de operación interno de la aplicación. OLDDUR Duración estimada actual (en minutos), tal y como la proporciona la descripción de la aplicación. CURDUR Medición de la duración que la operación actual ha estado activa en la estación de trabajo. NEWDUR Nueva duración estimada que guardará Tivoli Workload Scheduler for z/OS en el registro de descripción de la aplicación. Si se establece este parámetro, el valor mínimo es 1 y el valor máximo es 5999. Salida de filtrado de sucesos (EQQUX004) Se invoca EQQUX004 cuando un grabador de sucesos de Tivoli Workload Scheduler for z/OS va a grabar un suceso en el conjunto de datos de suceso o, donde se utiliza EWSEQNO, añade el suceso a la cola XCF o NCF. En esta salida, puede seleccionar entre descartar sucesos creados por las salidas de JES y SMF o indicar que un suceso que se colocaría normalmente en cola en JCC no es procesado por JCC. Esta salida normalmente se utiliza para filtrar los sucesos creados por el trabajo no de producción. Si ejecuta un número considerable de trabajos de prueba y otro trabajo, y los estándares de denominación de trabajos le permiten hacerlo, considere utilizar EQQUX004 para filtrar el trabajo no de producción. La biblioteca de ejemplos SEQQSAMP creada durante la instalación contiene la salida EQQUX004, que es un ejemplo de salidas de filtrado de sucesos. Instalación de la salida El módulo de carga que implementa la salida de filtrado de sucesos se debe enlazar a una biblioteca autorizada por APF en la concatenación LNKLST o definida mediante la sentencia STEPLIB DD en el procedimiento de JCL de Tivoli Workload Scheduler for z/OS. El módulo de carga se debe enlazar con RMODE(24) según las restricciones normales de z/OS. Tivoli Workload Scheduler for z/OS invoca la salida en AMODE 24; el parámetro AMODE especificado cuando se enlazó no tiene ningún efecto. Capítulo 4. Salidas de Tivoli Workload Scheduler for z/OS 243 Salida EQQUX004 Interfaz a la salida Se invoca la salida de filtrado de sucesos en modalidad de tarea, estado de problema y clave 8, y la tarea de paso de trabajo está autorizada por APF. La tarea activa se ejecuta con la misma autorización de acceso que la tarea de paso de trabajo. La salida debe restaurar este estado antes de volver a al emisor de la llamada. Se pasa el control a la salida utilizando la instrucción BAL. La salida se debe devolver al emisor de la llamada utilizando la dirección y la modalidad de direccionamiento pasadas a éste, normalmente el registro 14. Si la salida termina anormalmente, se marca como no ejecutable; Tivoli Workload Scheduler for z/OS no intenta invocar de nuevo la salida. Cuando se especifica la salida, el registro 1 contiene la dirección de la lista de parámetros. Se utiliza cada una de las direcciones de esta lista para ubicar el valor del parámetro. Los siguientes son los parámetros que se pasan a la salida: Parámetros de EQQUX004 JOBNAME RETCODE EXR CDSP CCMACT 244 DS DS DS DS DS CL8 F CL80 A CL1 (Nombre de trabajo actual) (Código de retorno) (Registro de salida) (Dirección de información de conjunto de datos) (Acción de gestión de catálogos, en blanco o D) JOBNAME Nombre del trabajo para el que se ha reconocido el suceso de seguimiento de trabajos y para el que se grabará un registro de suceso en el conjunto de datos de suceso. RETCODE Lo establece la salida. La comprobación de terminación de trabajo reconoce los valores siguientes: 0 Retorno normal. El grabador de sucesos continúa el proceso normal; el suceso se graba en el conjunto de datos de suceso. Si el suceso es un suceso de terminación de trabajo (tipo 3P), se pasa a JCC si JCC está activo. 4 Ningún proceso de JCC para este suceso. El suceso se graba en el conjunto de datos de suceso pero no se pasa a JCC para su proceso. 8 No es un suceso de planificador. El suceso no se graba en el conjunto de datos de suceso y no se pasa a JCC para su proceso. Sin embargo, si el suceso es un suceso de lector (tipo 1) y el trabajo lo mantenía una salida de seguimiento de trabajos de planificador, el suceso se libera de su retención por parte del grabador de sucesos. EXR Registro de salida que describe el suceso de seguimiento de trabajos. Este registro lo crea la salida de SMF o JES que reconoce el suceso. El desplazamiento de número de trabajo, EXRJOBID, del registro de salida contiene JOB como los primeros tres caracteres si el suceso se crea para un trabajo. EXRJOBID contiene STC como los primeros tres caracteres si el suceso se crea para una tarea iniciada. CDSP En releases anteriores, la dirección que apunta a una lista de conjuntos de datos que es posible que sea para acciones de gestión de catálogos. IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Salida EQQUX004 La función de gestión de catálogos ha sido sustituida por una nueva función denominada reinicio y limpieza. El parámetro CDSP se mantiene sólo por razones de compatibilidad con las salidas que ya se han escrito. CCMACT Acción de operación de gestión de catálogos. Esta gestión de catálogos anterior se ha reestructurado completamente y ha sido sustituida por una nueva función denominada reinicio y limpieza, donde este parámetro ya no es aplicable. Se mantiene sólo por razones de compatibilidad con las salidas que ya se han escrito. Salida de archivado de SYSOUT (EQQUX005) La salida EQQUX005 la invoca la comprobación de terminación de trabajo (JCC) durante el proceso de conjuntos de datos de SYSOUT para un trabajo. Se puede invocar la salida varias veces para el mismo trabajo conforme JCC avanza por los distintos conjuntos de datos de SYSOUT. Esta salida se utiliza normalmente para cambiar la disposición SYSOUT definida, en función del resultado satisfactorio o anómalo del trabajo. EQQUX005 es una salida de rastreador, aunque el resultado satisfactorio o anómalo de una operación lo determina en última instancia el controlador. La biblioteca de ejemplos SEQQSAMP creada durante la instalación contiene la salida EQQX5ASM, que es un ejemplo de salidas de archivado de SYSOUT. Para obtener más información sobre este ejemplo, consulte “Salida de archivado de SYSOUT” en la página 424. Instalación de la salida El módulo de carga que implementa la salida de archivado de SYSOUT se debe enlazar a una biblioteca autorizada por APF en la concatenación LNKLST o definida mediante la sentencia STEPLIB DD en el procedimiento de JCL de Tivoli Workload Scheduler for z/OS. El módulo de carga se debe enlazar con RMODE(24) según las restricciones normales de z/OS. Tivoli Workload Scheduler for z/OS invoca la salida en AMODE 24; el parámetro AMODE especificado cuando se enlazó no tiene ningún efecto. Interfaz a la salida Se invoca la salida de archivado de SYSOUT en modalidad de tarea, estado de problema y clave 8, y la tarea de paso de trabajo está autorizada por APF. La tarea activa se ejecuta con la misma autorización de acceso que la tarea de paso de trabajo. La salida debe restaurar este estado antes de volver a al emisor de la llamada. Se pasa el control a la salida utilizando la instrucción BAL. La salida se debe devolver al emisor de la llamada utilizando la dirección y la modalidad de direccionamiento pasadas a éste, normalmente el registro 14. Si la salida termina anormalmente, se marca como no ejecutable; Tivoli Workload Scheduler for z/OS no intenta invocar de nuevo la salida. Cuando se especifica la salida, el registro 1 contiene la dirección de la lista de parámetros. Se utiliza cada una de las direcciones de esta lista para ubicar el valor del parámetro. Los siguientes son los parámetros que se pasan a la salida: Capítulo 4. Salidas de Tivoli Workload Scheduler for z/OS 245 Salida EQQUX005 Parámetros de EQQUX005 CALLTYPE RETCODE JOBNAME JOBNUM CLASS SIZE RECFM USERAREA RECORD ERRCODE SYSDISP CALLTYPE RETCODE 246 DS DS DS DS DS DS DS DS DS DS DS CL1 F CL8 CL8 CL1 F X A X H CL2 (Tipo de llamada) (Código de retorno) (Nombre de trabajo actual) (Número de trabajo actual) (Clase SYSOUT actual) (Tamaño de registro SYSOUT actual) (Formato de registro actual) (Dirección de información relacionada con el trabajo) (Registro de suceso o SYSOUT actual) (Código de error actual) (Disposición de SYSOUT de trabajo) Define las circunstancias en las que se invoca la salida: B Se invoca la salida para procesar un registro SYSOUT que no ha sido procesado aún por JCC ya que JCC está realizando un salto hacia adelante en el conjunto de datos de SYSOUT actual. C JCC está finalizando. Se invoca la salida por última vez. E No existe más salida para el trabajo actual. Ésta es la última llamada para el trabajo actual. F Se invoca la salida porque JCC está intentando procesar un trabajo que ha fallado. I JCC se está iniciando. Se invoca la salida por primera vez. J JCC está empezando a procesar un nuevo trabajo. Ésta es la primera llamada para el trabajo actual. N Se pasa un registro SYSOUT normal a la salida. S Se invoca la salida porque JCC ha encontrado un error al procesar el conjunto de datos de SYSOUT actual. T Se invoca la salida para procesar un registro de SYSOUT que ha hecho que se cree un registro de incidencia en el conjunto de datos de registro de incidencias de JCC. Lo establece la salida. Estos valores los reconoce JCC: 0 Retorno normal. JCC continúa el proceso normal. 4 Detiene la exploración del conjunto de datos de SYSOUT actual. JCC continúa leyendo el conjunto de datos actual e invoca la salida de archivado para cada uno de los registros, pero no realiza ningún otro proceso para el conjunto de datos actual. 8 Detiene la invocación a la salida de archivado para este conjunto de datos. JCC continúa leyendo el conjunto de datos actual pero no invoca de nuevo la salida de archivado. Se invocará la salida si hay más conjuntos de datos de SYSOUT en el trabajo actual. 12 Detiene la invocación a la salida de archivado. JCC continúa el proceso normal pero no invoca de nuevo la salida de archivado. Debe detener JCC e iniciarlo de nuevo para volver a activar la salida. IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Salida EQQUX005 JOBNAME Nombre del trabajo para el que se invoca la salida de archivado. JOBNUM Número de trabajo actual con el formato JOBnnnnn, donde nnnnn es un número. CLASS Clase SYSOUT actual. SIZE Tamaño del registro SYSOUT actual. RECFM Formato de registro actual definido de la misma forma que el campo DCBRECFM en la correlación de un DCB. USERAREA Dirección que contiene información sobre el trabajo actual y el conjunto de datos de SYSOUT actual en un área correlacionada de la forma siguiente: Correlación de USERAREA JOBNAME JOBSTART JOBEND DATE SYSTEM TRKID STEPNAME DSNAME SYSCODE USERCODE JOBNUM DS DS DS DS DS DS DS DS DS DS DS CL8 CL8 CL8 CL8 CL5 CL8 CL8 CL44 CL4 CL5 CL8 (Nombre del trabajo) (Hora de inicio del trabajo, formato HH.MM.SS) (Hora de finalización del trabajo, formato HH.MM.SS) (Fecha actual, formato AA/MM/DD) (Nombre del sistema z/OS) (Identificación de seguimiento) (Nombre de paso de IEF450I) (Nombre de conjunto de datos de SYSOUT) (Código de terminación anómala del sistema de IEF450I) (Código de terminación anómala de usuario de IEF450I) (Número de trabajo) RECORD Registro SYSOUT actual. SIZE se debe utilizar para determinar el tamaño del registro actual. ERRCODE Código de error del trabajo actual. En JES2, el código de error es distinto de cero sólo cuando se invoca la salida para un registro SYSOUT que ha establecido un EID distinto de cero después de correlacionar una entrada de tabla de JCC. Las llamadas subsiguientes del mismo trabajo tendrán ERRCODE establecido en cero, a menos que el nuevo EID lo establezca una coincidencia subsiguiente. Cuando se invoca la salida porque JCC ha empezado a procesar un nuevo trabajo. SYSDISP Información de disposición de SYSOUT en vigor para el trabajo actual. Consulte la descripción de SYSOUTDISP en la sentencia JCCOPTS (página 81) para obtener más información sobre este parámetro. La salida puede cambiar la disposición de SYSOUT para un trabajo en cualquier momento, pero la disposición normal se restaurará cuando JCC empiece a procesar el trabajo siguiente. Salida de creación de registro de incidencia (EQQUX006) La salida EQQUX006 la invoca la comprobación de terminación de trabajo para crear un registro de incidencia cuando la tabla de mensajes de JCC especifica que se debe crear un registro de incidencia para el registro SYSOUT actual. Esta salida actualiza el archivo de incidencias con las condiciones de error determinadas por la función de registro de incidencias de JCC. Capítulo 4. Salidas de Tivoli Workload Scheduler for z/OS 247 Salida EQQUX006 La biblioteca de ejemplos SEQQSAMP creada durante la instalación contiene un ejemplo de salidas de creación de registro de incidencias. El ejemplo consta de dos miembros de la biblioteca de ejemplos: EQQX6ASM Ejemplo EQQUX006 EQQX6JOB Esqueleto de JCL de trabajos por lotes de ejemplo que utilizará el ejemplo EQQX6ASM. Consulte los propios miembros de la biblioteca de ejemplos para obtener información adicional. Este ejemplo crea registros en el conjunto de datos de incidencia como los siguientes: Registro de incidencia de ejemplo 86/10/04 * JOBNAMEJ * JOB 5788 * 20.29 * 20.30 * MVS1 * 0001 OK-RC8 IEF142I JOBNAMEJ AMS8 - STEP WAS EXECUTED - COND CODE 0008 La salida de creación de registro de incidencia predeterminada normalmente genera 2 registros para cada incidencia que encuentra JCC. El primer registro identifica el trabajo y sus horas de inicio y finalización. El segundo registro contiene los primeros 72 caracteres del registro SYSOUT que han hecho que se cree la incidencia. Puede utilizar la salida de creación de registro de incidencia si necesita generar registros de incidencias con más información o con una correlación distinta. EQQUX006 es una salida del comprobador de seguimiento y el resultado satisfactorio o anómalo de una operación lo determina en última instancia el controlador. Instalación de la salida El módulo de carga que implementa la salida de creación de registro de incidencia se debe enlazar a una biblioteca autorizada por APF en la concatenación LNKLST o definida por la sentencia STEPLIB DD en el procedimiento de JCL de IBM Tivoli Workload Scheduler for z/OS. El módulo de carga se debe enlazar con RMODE(24) según las restricciones normales de z/OS. IBM Tivoli Workload Scheduler for z/OS invoca la salida en AMODE 24; el parámetro AMODE especificado cuando se enlazó no tiene ningún efecto. Interfaz a la salida Se invoca la salida de creación de registro de incidencia en modalidad de tarea, estado de problema y clave 8 y la tarea de paso de trabajo está autorizada por APF. La tarea activa se ejecuta con la misma autorización de acceso que la tarea de paso de trabajo. La salida debe restaurar este estado antes de volver a al emisor de la llamada. Se pasa el control a la salida utilizando la instrucción BAL. La salida se debe devolver al emisor de la llamada utilizando la dirección y la modalidad de direccionamiento pasadas a éste, normalmente el registro 14. Si la salida termina anormalmente, se marca como no ejecutable; Tivoli Workload Scheduler for z/OS no intenta invocar de nuevo la salida. 248 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Salida EQQUX006 Cuando se especifica la salida, el registro 1 contiene la dirección de la lista de parámetros. Se utiliza cada una de las direcciones de esta lista para ubicar el valor del parámetro. Los siguientes son los parámetros que se pasan a la salida: Parámetros de EQQUX006 AREA NRECS RSIZE DATE JOBNAME JOBNUM JOBSTART JOBEND SYSTEM EID TID STEPNAME RFLAG RECORD RETCODE DS DS DS DS DS DS DS DS DS DS DS DS DS DS DS CL1024 F F CL8 CL8 CL8 CL8 CL8 CL5 CL8 CL8 CL8 CL1 CL72 F (Área de creación de registro) (Número de registros creados) (Tamaño de registro de conjunto de datos de incidencia) (Fecha actual, formato AA/MM/DD) (Nombre del trabajo) (Número de trabajo) (Hora de inicio del trabajo, formato HH.MM.SS) (Hora de finalización del trabajo, formato HH.MM.SS) (Nombre del sistema z/OS) (Código de error) (Identificación de seguimiento) (Nombre de paso) (Distintivo de registro) (Inicio del registro SYSOUT actual) (Código de retorno) AREA Área de creación de registro que actualizará la salida. Esta área está en blanco cuando se invoca la salida. NRECS Lo establece la salida para indicar a JCC cuántos registros se han creado en el área de creación de registro. RSIZE Proporciona el tamaño de cada registro creado. La salida debe crear estos registros en el área de creación, cada registro debe ser contiguo al registro precedente y la salida no debe actualizar almacenamiento fuera del área de creación. DATE Fecha del trabajo que ha hecho que se invoque la salida de creación de registro de incidencia. JOBNAME Nombre del trabajo que ha hecho que se invoque la salida de creación de registro de incidencia. JOBNUM Número de trabajo del trabajo que ha hecho que se invoque la salida de creación de registro de incidencia. JOBSTART Hora de inicio del trabajo que ha hecho que se invoque la salida de creación del registro de incidencias. JOBEND Hora de finalización del trabajo que ha hecho que se invoque la salida de creación del registro de incidencias. SYSTEM Identifica el sistema en el que se ha ejecutado el trabajo. EID Contiene el código de error que está establecido para este trabajo. TID Contiene la información de seguimiento de la entrada de la tabla de mensajes actual. STEPNAME Identifica el nombre del paso en el trabajo actual para el que se invoca la salida. RFLAG Tiene el valor T si se invoca la salida de creación de registro de incidencia porque se ha encontrado una coincidencia en la tabla de mensajes para un registro SYSOUT. Si RFLAG tiene cualquier otro valor, se invoca la salida para una incidencia que no está relacionada con un registro SYSOUT determinado. Capítulo 4. Salidas de Tivoli Workload Scheduler for z/OS 249 Salida EQQUX006 RECORD Contiene los 72 primeros caracteres del registro SYSOUT actual cuando RFLAG tiene el valor T. RETCODE Lo establece la salida. JCC actualiza el conjunto de datos de registro de incidencias sólo si este parámetro tiene un valor de cero. Salida de cambio de estado de la operación (EQQUX007) Se invoca la salida de cambio de estado de la operación (EQQUX007) cada vez que una operación del plan actual cambia de estado. También se invoca la salida cuando se añade una nueva operación al plan actual mediante una función que no sea los trabajos de planificación diaria; por ejemplo, mediante el diálogo MCP o PIF. Se invoca la salida cuando se añade la operación a una aparición existente o como resultado de una nueva aparición añadida al plan actual. No se invoca la salida EQQUX007 para operaciones que se añaden a la planificación diaria. Se puede utilizar la salida para modificar el campo USERDAT del parámetro OPERAREA. La salida no puede modificar otros parámetros pasados a ella ni otros datos o recursos de Tivoli Workload Scheduler for z/OS. Puede examinar los parámetros y realizar algunas acciones externas a Tivoli Workload Scheduler for z/OS en función de la información de los parámetros. Puede utilizar EQQUX007 para las tareas siguientes: v Notificar errores a un sistema de gestión de problemas, como por ejemplo la v Generar un mensaje WTO (write-to-operator). Este tipo de mensaje lo podría manejar NetView o un programa de proceso de mensajes similar para generar alertas o para desencadenar otros procesos. La biblioteca de ejemplos de Tivoli Workload Scheduler for z/OS creada durante la instalación contiene una salida EQQUX007 de ejemplo escrita en lenguaje ensamblador. Esta salida de ejemplo notifica los errores de trabajos por lotes al producto de Información/Gestión. El ejemplo consta de dos miembros de la biblioteca de ejemplos: EQQX7ASM Programa de lenguaje ensamblador del ejemplo EQQUX007 y JCL para ensamblarlo y enlazarlo EQQX7JOB Esqueleto de JCL de trabajo por lotes de ejemplo que utilizará el ejemplo EQQUX007. Consulte los propios miembros de la biblioteca de ejemplos para obtener información adicional. Nota: Debido a que es posible que el mismo suceso se procese una segunda vez en una situación de recuperación y durante la entrega del plan actual, esto se debe tener en cuenta al codificar la salida. Si NO se desea la invocación de la salida durante la recuperación o entrega de Tivoli Workload Scheduler for z/OS, codifique la salida para comprobar si el emisor de la llamada (CALLER) es NMM. La única circunstancia en la que NMM invoca EQQUX007 es durante la recuperación del plan de trabajo y entrega del plan diario. Instalación de la salida El módulo de carga que implementa la salida de cambio de estado de la operación se debe enlazar a una biblioteca autorizada por APF en la concatenación LNKLST o definida mediante la sentencia STEPLIB DD en el procedimiento de JCL de Tivoli 250 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Salida EQQUX007 Workload Scheduler for z/OS. Si el módulo de carga realiza alguna operación de entrada o salida, se debe enlazar con RMODE(24) según las restricciones normales de z/OS. O se puede enlazar con RMODE(ANY). Tivoli Workload Scheduler for z/OS invoca la salida en AMODE 31; el parámetro AMODE especificado cuando se enlazó no tiene ningún efecto. Interfaz a la salida Se invoca la salida de cambio de estado de la operación en modalidad de tarea, estado de problema y clave 8, y la tarea de paso de trabajo está autorizada por APF. La tarea activa se ejecuta con la misma autorización de acceso que la tarea de paso de trabajo. La salida debe restaurar este estado antes de volver a al emisor de la llamada. Se pasa el control a la salida utilizando la instrucción BAL. La salida se debe devolver al emisor de la llamada utilizando la dirección y la modalidad de direccionamiento pasadas a éste, normalmente el registro 14. La salida se especifica en AMODE 31 pero se debe cambiar a AMODE 24 antes de realizar cualquier operación de entrada o salida y, a continuación, volver a cambiar a AMODE 31 antes de volver al emisor de la llamada. Cuando se especifica la salida, el registro 1 contiene la dirección de la lista de parámetros. Se utiliza cada una de las direcciones de esta lista para ubicar el valor del parámetro. Los siguientes son los parámetros que se pasan a la salida: Parámetros de EQQUX007 NEWSTAT OLDSTAT OPNUM CALLER ERRCODE WSNAME ADNAME OWNER GROUP JOBAREA OPERAREA USRAREA EXSTAT OCCPTR OPRPTR UFNUM UFPTR NEWSTAT DS DS DS DS DS DS DS DS DS DS DS DS DS DS DS DS DS CL1 CL1 H CL4 CL4 CL4 CL16 CL16 CL8 A A A CL1 A A F A (Nuevo estado de la operación) (Estado anterior de la operación) (Número de operación) (Identificación del emisor de la llamada) (Código de error) (Nombre de la estación de trabajo) (Nombre de la aplicación) (Nombre de propietario de la aplicación) (Nombre del grupo de autorización) (Dirección de datos relacionados con el trabajo) (Dirección de datos relacionados con la operación) (Campo definido por el usuario) (Estado ampliado de la operación) (Dirección de datos de la aparición) (Dirección de datos de la operación) (Número de campos de usuario) (Dirección de área de campos de usuario) Define el nuevo estado de la operación actual. Son posibles los valores siguientes: A Ha llegado a la estación de trabajo C Completada E Ha finalizado con errores I Interrumpido R Preparada para proceso * Preparada para proceso (la predecesora en estación de trabajo sin información se ha completado) Capítulo 4. Salidas de Tivoli Workload Scheduler for z/OS 251 Salida EQQUX007 S Activa (iniciada) W En espera. OLDSTAT Define el estado anterior de la operación actual. Son posibles los mismos valores que para el nuevo estado, además del espacio en blanco. Los espacios en blanco indican que la operación ha sido añadida al plan actual mediante una función distinta de los trabajos de planificación diaria. No se realiza ninguna invocación a EQQUX007 cuando se añaden operaciones mediante trabajos de planificación diaria. OPNUM Es el número de operación de la operación actual. CALLER Identifica la función de Tivoli Workload Scheduler for z/OS que ha invocado la salida. Son posibles los valores siguientes: AR Tarea de recuperación automática EM Tarea del gestor de sucesos GS Tarea de servicio general, pero no de modificar plan actual MCP Función de modificar plan actual en la tarea de servicio general NMM Tarea del gestor de modalidad normal WSA Tarea de analizador de estación de trabajo. ERRCODE Código de error de la operación actual si el nuevo estado es E. WSNAME Nombre de la estación de trabajo donde está activa o pasará a estar activa la operación actual. ADNAME Nombre de aplicación de la operación actual. OWNER Nombre del propietario de la aplicación actual. GROUP Nombre del grupo de autorización al que pertenece la operación actual. JOBAREA Dirección de un área que contiene información sobre los cambios de estado relacionados con un trabajo específico. El área relacionada con el trabajo se distribuye de la forma siguiente: JOBAREA JOBNAME JOBNUM DATE JOBSTART JOBEND STEPNAME ABCODE USRCODE ORIGNJE PSTEPNAM DS DS DS DS DS DS DS DS DS DS CL8 CL8 CL8 CL8 CL8 CL8 CL4 CL5 CL8 CL8 (Nombre del trabajo) (Número de trabajo) (Fecha actual, formato AA/MM/DD) (Hora de inicio del trabajo, formato HH.MM.SS) (Hora de finalización del trabajo, formato HH.MM.SS) (Nombre de paso) (Código de terminación anómala del sistema, formato Shhh) (Código de terminación anómala del usuario, formato Uhhh) (Nombre del nodo NJE de origen) (Nombre de paso de procedimiento) Los campos JOBNAME y DATE están siempre presentes para cambios de estado en estaciones de trabajo de sistema y de impresora con información. JOBNUM está presente cuando una operación en una de estas estaciones de trabajo cambia su estado de S a C. Cuando una estación de trabajo tolerante a errores envía el trabajo, los tres primeros caracteres del valor JOBNUM Tivoli Workload Scheduler for z/OS se establecen en UNX. 252 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Salida EQQUX007 El estado cambia a S (iniciada). El valor de JOBNUM sólo puede cambiar si se vuelve a ejecutar la operación. JOBSTART está presente cuando el nuevo estado en las estaciones de trabajo de sistema y de impresora con información automática sea S (iniciado), C (completado), E (finalizado con error) o I (interrumpido). JOBEND está presente cuando el nuevo estado en una de estas estaciones de trabajo es C o E. STEPNAME, PSTEPNAM, ABCODE y USRCODE están presentes sólo para trabajos que han terminado anormalmente durante la ejecución. ORIGNJE está presente para operaciones de proceso cuando el nuevo estado es C o E. Cuando el estado de una operación cambia de C o E a S, C, E o I, determinados campos JOBAREA se establecen en sus valores anteriores para esa operación. Los campos en el área relacionada con el trabajo están en blanco si la información no está disponible cuando se invoca la salida. Dirección de un área que contiene información sobre la operación cuyo estado está cambiando. Esta área se correlaciona de la forma siguiente: OPERAREA OPERAREA OPERTEXT APPLIA OPERIA PSTART PLEND DEADLINE USERDAT RSPRES RSERR RSUSER * RSREASN RSPANEL XJNAME SAWS DS DS DS DS DS DS DS DS DS DS DS DS DS DS CL24 CL10 CL10 CL10 CL10 CL10 CL16 CL1 CL4 CL16 (Descripción de la operación) (Llegada de entrada de la aplicación, formato AAMMDDHHMM) (Llegada de entrada de la operación, formato YYMMDDHHMM) (Inicio planificado, formato AAMMDDHHMM) (Finalización planificada, formato AAMMDDHHMM) (Fecha límite de la operación, formato AAMMDDHHMM) (Campo de datos de usuario) (Y=hay datos de razón, N=no hay datos de razón) (El código de error establecido por el usuario del diálogo) (Los datos de usuario del diálogo: es igual que USERDAT como entrada a la salida) CL300(Los datos de ’razón para reinicio’ del diálogo) CL8 (El panel donde se ha iniciado el reinicio) CL54 (Nombre ampliado del trabajo) CL1 (Nueva estación de trabajo de automatización) USRAREA Campo de usuario que también se pasa a la salida EQQUX000. Contiene datos válidos sólo si tiene una salida EQQUX000 que coloca algunos datos en él. Tivoli Workload Scheduler for z/OS no utiliza ni actualiza este campo. EXSTAT Define el código de estado ampliado de la operación. Consulte la publicación IBM Tivoli Workload Scheduler for z/OS Gestión de la carga de trabajo para ver una descripción de los códigos válidos. Por razones de rendimiento, la salida de usuario EQQUX007 no proporciona actualmente el estado ampliado 'X' (en espera del recurso). Se ha añadido un nuevo valor, 'Z', válido para todos los códigos de estado y tipos de estación de trabajo actuales para indicar que se ha producido un error en el proceso de actualización de DOA. En este caso, se emite el mensaje EQQE106I en EQQMLOG. OCCPTR La dirección de los datos comunes del registro CPLREC3C. Capítulo 4. Salidas de Tivoli Workload Scheduler for z/OS 253 Salida EQQUX007 OPRPTR La dirección de los datos comunes del registro CPLREC3P. USRFNR El número de registros de campos de usuario en USRFAREA. USRFAREA Dirección del área del campo de usuario. Se distribuye del modo siguiente: USRFAREA USRFNAME DS USRFVAL DS CL16 CL54 (Nombre del campo de usuario) (Valor del campo de usuario) Salida de iniciación de la operación (EQQUX009) Se invoca la salida de iniciación de operación (EQQUX009) cuando una operación está preparada para ser iniciada en una estación de trabajo que especifica un ID de destino definido por el usuario. Puede utilizar EQQUX009 para comunicarse con entornos operativos que no dan soporte al comprobador de seguimiento. La biblioteca de ejemplos de Tivoli Workload Scheduler for z/OS que se ha creado durante la instalación contiene estos programas de ejemplo para demostrar cómo puede utilizar EQQUX009: EQQUX9N Ejemplo EQQUX009 que utiliza NJE para comunicarse con VM EQQX9OS2 Ejemplo EQQUX009 que utiliza TCP/IP para comunicarse con OS/2 EQQX9AIX Ejemplo EQQUX009 que utiliza TCP/IP para comunicarse con AIX. Consulte el Apéndice C, “Biblioteca de ejemplos (SEQQSAMP)”, en la página 419 para obtener más información. Instalación de la salida El módulo de carga que implementa la salida de iniciación de operación se debe enlazar a una biblioteca autorizada por APF en la concatenación LNKLST o definida mediante la sentencia STEPLIB DD en el procedimiento de JCL de Tivoli Workload Scheduler for z/OS. Si el módulo de carga realiza alguna operación de entrada o salida, se debe enlazar con RMODE(24) según las restricciones normales de z/OS. O se puede enlazar con RMODE(ANY). Tivoli Workload Scheduler for z/OS invoca la salida en AMODE 31; el parámetro AMODE especificado cuando se enlazó no tiene ningún efecto. Interfaz a la salida Se invoca salida de iniciación de operación en modalidad de tarea, estado de problema y clave 8 y la tarea de paso de trabajo está autorizada por APF. La tarea activa se ejecuta con la misma autorización de acceso que la tarea de paso de trabajo. La salida debe restaurar este estado antes de volver a al emisor de la llamada. Se pasa el control a la salida utilizando la instrucción BAL. La salida se debe devolver al emisor de la llamada utilizando la dirección y la modalidad de direccionamiento pasadas a éste, normalmente el registro 14. 254 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Salida EQQUX009 La salida se especifica en AMODE 31 pero se debe cambiar a AMODE 24 antes de realizar cualquier operación de entrada o salida y, a continuación, volver a cambiar a AMODE 31 antes de volver al emisor de la llamada. Si la salida termina anormalmente, se marca como no ejecutable; Tivoli Workload Scheduler for z/OS no intenta invocar de nuevo la salida. Cuando se especifica la salida, el registro 1 contiene la dirección de la lista de parámetros. Se utiliza cada una de las direcciones de esta lista para ubicar el valor del parámetro. Los siguientes son los parámetros que se pasan a la salida: Parámetros de EQQUX009 DEST DS CL8 MCAUSERF DS A OPCTOKEN DS F WSNAME ADID IA OPNUM JOBNAME AREALEN DATAP RETC DS DS DS DS DS DS DS DS CL4 CL16 CL10 CL3 CL8 F A F (ID de destino definido por el usuario) (Dirección establecida por el usuario en la salida EQQUX000) (Señal utilizada para identificar de forma exclusiva la operación) (Nombre de la estación de trabajo) (Nombre de la aplicación) (Fecha y hora de llegada de entrada, formato AAMMDDHHMM) (Número de operación) (Nombre del trabajo) (Longitud del área de datos pasada, cero si no hay datos) (Dirección de los datos pasados desde JBLIB/JSFILE) (Código de retorno establecido por la salida) DEST Define el ID de destino definido por el usuario desde la estación de trabajo de la operación actual. MCAUSERF Es el campo de usuario que permite asignar recursos en la salida de inicio/detención, EQQUX000, que esta salida puede utilizar posteriormente. Este campo contiene el valor establecido por la salida EQQUX000. Tivoli Workload Scheduler for z/OS no utiliza ni actualiza este campo. OPCTOKEN Contiene la señal asignada para la operación actual. La debe almacenar el usuario y utilizar como entrada al invocar OPSTAT para identificar de forma exclusiva una operación. WSNAME Identifica el nombre de la estación de trabajo para la operación actual. ADID Nombre de aplicación de la operación actual. IA Contiene la fecha y hora de llegada de entrada para la operación actual con el formato AAMMDDHHMM. OPNUM Número de operación para la operación actual. JOBNAME Nombre de trabajo definido para la operación actual AREALEN Contiene la longitud del área de datos a la que apunta DATAP. Si la longitud es cero, no se pasa ningún dato. DATAP Dirección de un área que contiene los datos pasados a la salida desde la biblioteca de JCL o el archivo de configuración de trabajo. Los datos pueden tener cualquier formato; probablemente no sería JCL de z/OS. RETC Código de retorno establecido por la salida. Son válidos los valores siguientes: Capítulo 4. Salidas de Tivoli Workload Scheduler for z/OS 255 Salida EQQUX009 0 Retorno normal, el proceso de Tivoli Workload Scheduler for z/OS continúa. 4 La operación ha fallado. Tivoli Workload Scheduler for z/OS realizará la acción especificada por la palabra clave SUBFAILACTION de la sentencia JTOPTS. 8 Anomalía de comunicación. Tivoli Workload Scheduler for z/OS generará automáticamente un suceso de fuera de línea para todas las estaciones de trabajo conectadas a este destino. No se invocará la salida de nuevo para este destino hasta que el estado de la estación de trabajo se notifique como activo. El estado de la operación que la salida estaba procesando se establece según la palabra clave SUBFAILACTION. Si la salida devuelve un valor en RETC que no se considera válido, se ignorará Tivoli Workload Scheduler for z/OS tratará el RETC como si se hubiera devuelto 0. En este caso se emite el mensaje EQQF010I al registro de mensajes del controlador. Si la salida termina anormalmente, se marca como no ejecutable y se emite el mensaje EQQF011. El estado de la operación que la salida estaba procesando se establece según la palabra clave SUBFAILACTION. Salida de grabación de registro de seguimiento de trabajos (EQQUX011) Se invoca la salida EQQUX011 inmediatamente antes de que Tivoli Workload Scheduler for z/OS grabe una entrada del registro de seguimiento de trabajos. Puede utilizar esta salida para configurar el procedimiento de recuperación tras desastre, manteniendo registros de seguimiento de trabajos remotos en línea en un centro de datos secundario de copia de seguridad en templado. La biblioteca de ejemplos SEQQSAMP creada durante la instalación contiene la salida EQQUX011, que es un ejemplo de salidas de grabación de registro de seguimiento de trabajos. Para obtener información sobre esta biblioteca y sus ejemplos, consulte Apéndice C, “Biblioteca de ejemplos (SEQQSAMP)”, en la página 419. Instalación de la salida El módulo de carga que implementa la salida de grabación de registro de seguimiento de trabajos se debe enlazar a una biblioteca autorizada por APF en la concatenación LNKLST o definida mediante la sentencia STEPLIB DD en el procedimiento de JCL de controlador. El módulo de carga se puede enlazar con RMODE(24) o RMODE(ANY). El módulo de carga se debe enlazar con como mínimo un atributo reutilizable. Tivoli Workload Scheduler for z/OS invoca la salida en AMODE 31; el parámetro AMODE especificado cuando se enlazó no tiene ningún efecto. Interfaz a la salida Se invoca la salida de grabación de registro de seguimiento de trabajos en modalidad de tarea, estado de problema y clave 8 y la tarea de paso de trabajo está 256 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Salida EQQUX011 autorizada por APF. La tarea activa se ejecuta con la misma autorización de acceso que la tarea de paso de trabajo. La salida restaura este estado antes de volver a al emisor de la llamada. Se pasa el control a la salida utilizando la instrucción BAL. La salida se devuelve al emisor de la llamada utilizando la modalidad de dirección direccionamiento pasada a ella, en general el registro 14. Si la salida termina anormalmente, se marca como no ejecutable; Tivoli Workload Scheduler for z/OS no intenta invocar de nuevo la salida. Cuando se especifica la salida, el registro 1 contiene la dirección de la lista de parámetros. Se utiliza cada una de las direcciones de esta lista para ubicar el valor del parámetro. Los siguientes son los parámetros que se pasan a la salida: Parámetros de EQQUX011 MCAUSERF DS JTLOGNUM DS SIZE DS TRL DS TQTOT DS A F F F F CPLCR CPLEND BUGMT GMTOF RETCODE CL10 CL10 XL8 F F DS DS DS DS DS (Campo de usuario) (Número de registro de seguimiento de trabajos actual) (Tamaño de registro de seguimiento de trabajos actual) (Dirección de registro de seguimiento de trabajos) (Entradas del registro de seguimiento de trabajos desde copia de seguridad de CP) (Fecha y hora de creación del plan actual) (FINALIZACIÓN DEL PERIODO DEL PLAN DP) (Fecha y hora de última actualización de CP - GMT) (Minutos de desplazamiento de GMT) (Código de retorno) MCAUSERF Campo de usuario que también se pasa a la salida EQQUX000. Tivoli Workload Scheduler for z/OS no utiliza ni actualiza el campo MCAUSERF. JTLOGNUM Número de registro de seguimiento de trabajos en el que se grabará la entrada del registro de seguimiento de trabajos. SIZE Tamaño, en bytes, de la entrada del registro de seguimiento de trabajos que se grabará. TRL Dirección de la entrada del registro de seguimiento de trabajos. TQTOT Número total de entradas del registro de seguimiento de trabajos (incluido la entrada del registro de seguimiento de trabajos actual) desde la última copia de seguridad de CP. CPLCR Fecha y hora de creación del plan actual en la hora local. Tiene el formato AAMMDDHHMM. AA es la representación interna del año de Tivoli Workload Scheduler for z/OS - 00 es 1972, 24 es 1996 y 99 es 2071. CPLEND Fecha y hora de finalización del periodo de planificación diaria en la hora local. Tiene el formato AAMMDDHHMM. AA es la representación interna del año de Tivoli Workload Scheduler for z/OS - 00 es 1972, 24 es 1996 y 99 es 2071. BUGMT Es la fecha y hora de la última actualización de CP en GMT. Tiene el formato 0nAADDDFHHMMSSTH. Si n = 0, año es 19AA. Si n = 1, año es 20AA. GMTOF Es el desplazamiento de GMT en minutos. RETCODE Lo establece la salida. Se reconocen los valores siguientes: Capítulo 4. Salidas de Tivoli Workload Scheduler for z/OS 257 Salida EQQUX011 0 Retorno normal. El proceso continúa. 8 Detiene la invocación a la salida de grabación de entrada del registro de seguimiento de trabajos. Debe detener el controlador e iniciarlo de nuevo para volver a activar la salida. Todos los demás códigos de retorno se procesan como el código de retorno 8. Notas: 1. Es posible que el rendimiento del planificador empeore si la salida requiere un tiempo de proceso largo. 2. Mientras esta salida tiene control, el planificador no procesa ninguna nueva solicitud que requiera la actualización del registro de seguimiento de trabajos. 3. Se deben evitar las esperas del sistema, incluidas las esperas implícitas de operaciones de E/S. 4. Las grabaciones del registro de seguimiento de trabajos del planificador las realizan diversas tareas; por lo tanto, se invocará la salida desde distintas tareas indistintamente. 5. Cuando se diseñe la salida se deben tener en cuenta los comentarios anteriores. Salida de suceso de adaptación de trabajos (EQQUX013) Se invoca la salida EQQUX013 cuando Tivoli Workload Scheduler for z/OS va a enviar un trabajo por lotes o a iniciar una tarea iniciada. Utilice esta salida para impedir que se personalicen algunos trabajos con las sentencias //TIVDSTXX OUTPUT para generar una copia adicional de los conjuntos de datos JESDS para proceso de almacenes de datos. La biblioteca de ejemplos SEQQSAMP creada durante la instalación contiene la salida EQQUX013, que es un ejemplo de la salida de prevención de adaptación de trabajos. Para obtener información sobre esta biblioteca y sus ejemplos, consulte Apéndice C, “Biblioteca de ejemplos (SEQQSAMP)”, en la página 419. Instalación de la salida El módulo de carga que implementa la salida de prevención de adaptación de trabajos se debe enlazar a una biblioteca autorizada por APF en la concatenación LNKLST o a una biblioteca definida por la sentencia STEPLIB DD en el procedimiento de JCL de Tivoli Workload Scheduler for z/OS. El módulo de carga también se debe enlazar con los atributos RMODE(ANY) y AMODE(31). Interfaz a la salida Se invoca la salida de prevención de adaptación de trabajos en modalidad de tarea, estado de problema y clave 8 y la tarea de paso de trabajo está autorizada por APF. La tarea activa se ejecuta con la misma autorización de acceso que la tarea de paso de trabajo. La salida debe restaurar este estado antes de volver a al emisor de la llamada. Tivoli Workload Scheduler for z/OS invoca la salida en la modalidad de direccionamiento definida por el atributo AMODE del módulo de carga, que es una modalidad de direccionamiento de 31 bits, y por lo tanto la secuencia de trabajos pasada a la salida reside por encima de la línea de 16M. 258 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Salida EQQUX013 Se pasa el control a la salida utilizando la instrucción de BASSM. La salida debe volver a al emisor de la llamada utilizando la dirección pasada a éste, normalmente el registro 14. Se puede realizar el retorno de la salida en cualquier modalidad de direccionamiento. Cuando se especifica la salida, el registro 1 contiene la dirección de la lista de parámetros. Se utiliza cada una de las direcciones de esta lista para ubicar el valor del parámetro. Los siguientes son los parámetros que se pasan a la salida: Parámetros de EQQUX013 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | JOBNAME DS CL8 (Nombre del trabajo) JCLLEN DS F (Tamaño, en bytes, de secuencia de trabajos actual) JCLAREA DS n * CL80 (Todos los registros de la secuencia de trabajos) LATEOUT DS CL10 (Último inicio, formato AAMMDDHHMM) ESTDUR DS CL4 (Duración estimada, formato HHMM) NUMPS DS H (Número de servidores paralelos necesarios) NUMR1 DS H (Cantidad necesaria de recurso 1 de estación de trabajo) NUMR2 DS H (Cantidad necesaria de recurso 2 de estación de trabajo) SPECRES DS CL8 (Primeros 8 caracteres de nombre de primer recurso especial) ADID DS CL16 (Nombre de la aplicación actual) | | | | | | | | | Notas: 1. Para permitir más flexibilidad en la determinación de trabajos que no se personalizarán con las sentencias //TIVDSTxx OUTPUT, el JCL del trabajo que se está enviando se proporciona como entrada a esta salida. Sin embargo, para que funcione correctamente, la salida no debe modificar este JCL. 2. Un trabajo no se personaliza para el proceso de almacén de datos si la salida EQQUX013 devuelve un código de retorno de 0012 al analizador de la estación de trabajo. MCAUSERF GROUP RUSER OPERTYPE UPDAT JCLUSER JCLUTIME OPNUM IATIME OWNER SPECNR SPECBUF WSNAME XINFO XJNAMLEN WSCHENV CLEANUPT RETCO DS A (Campo de usuario) DS CL8 (Nombre de grupo de autorización actual) DS CL8 (Nombre del usuario de RACF que envía el trabajo) DS CL1 (J o S, para trabajo o tarea iniciada) DS C (Y o N, define origen de trabajo) DS CL8 (Último usuario que actualizó este trabajo) DS CL10 (Hora de última actualización, formato AAMMDDHHMM) DS F (Número de la operación) DS CL10 (Hora de entrada de llegada de aparición, AAMMDDHHMM) DS CL16 (Nombre de propietario de la aplicación) DS H (Número de recursos especiales) DS A (Almacenamiento intermedio de recursos especiales) DS CL4 (Nombre de la estación de trabajo de la operación) DS A (Dirección de información ampliada) DS F (Longitud de nombre de trabajo ampliado) DS CL 16 (Nombre del entorno de planificación) DS CL 1 (Tipo de limpieza) DS CL4 (Código de error de la operación) | JOBNAME Nombre del trabajo que se va a enviar. | JCLLEN Tamaño, en bytes, del trabajo. | JCLAREA Registro de JCL en el trabajo. | | LATEOUT El valor de la última hora de inicio que Tivoli Workload Scheduler for z/OS ha calculado para el trabajo. | ESTDUR La duración estimada de este trabajo Capítulo 4. Salidas de Tivoli Workload Scheduler for z/OS 259 Salida EQQUX013 | NUMPS El número de servidores paralelos necesarios | NUMR1 La cantidad de recurso 1 de estación de trabajo necesaria | NUMR2 La cantidad de recurso 2 de estación de trabajo necesaria | SPECRES Los 8 primeros caracteres del nombre de recurso especial | ADID Nombre de la aplicación de la que el trabajo forma parte. | | | MCAUSERF Campo de usuario que también se pasa a la salida EQQUX000. Tivoli Workload Scheduler for z/OS no utiliza el campo MCAUSERF. | RUSER El nombre del usuario de RACF que es propietario del trabajo. | OPERTYPE Tiene el valor J para trabajo o S para tarea iniciada. | | | UPDAT Tiene el valor Y si el trabajo actual se ha recuperado del conjunto de datos EQQJSnDS. En todos los demás casos, UPDAT tiene el valor N. | | GROUP Nombre del grupo de autorización al que pertenece la operación actual | | JCLUSER Nombre del último usuario de TSO que ha actualizado el trabajo actual. Este parámetro es significativo sólo si UPDAT es Y. | | JCLUTIME La fecha y hora de la última actualización del trabajo actual. Este parámetro es significativo sólo si UPDAT es Y. | OPNUM Número de operación de la operación que representa este trabajo | | IATIME Hora de llegada de entrada de la aparición de la aplicación a la que pertenece este trabajo | OWNER Nombre del propietario de la aplicación actual | SPECNR El número de nombres de recursos especiales en SPECBUF | | | | | | SPECBUF Una dirección a un almacenamiento intermedio que contiene un número de campos de 64 bytes. El número de campos de 64 bytes del almacenamiento intermedio se indica mediante SPECNR. Los primeros 44 bytes de cada campo contienen el nombre del recurso especial. Los últimos 2 bytes de cada campo están reservados para utilizarlos en el futuro. | WSNAME Nombre de la estación de trabajo de la operación. | | | | XINFO La dirección de los datos especificada en el campo de información ampliada del plan actual para la operación correspondiente. Si su valor es 0, no hay disponible ninguna información ampliada en el plan actual. | | | XJNAMLEN La longitud que especifica en el campo Nombre ampliado de la operación del plan actual para la operación correspondiente. Es un subcampo de la información ampliada disponible en el plan actual. | | | WSCHENV El nombre del entorno de planificación almacenado actualmente en el registro de operación de CP. Este valor puede ser modificado por la salida. | | | | RETCO Nombre de un campo que utiliza la salida de usuario para impedir que los trabajos se personalicen con los parámetros //TIVDSTxx OUTPUT para generar copias adicionales de los conjuntos de datos JESDS para proceso de almacenes de datos. 260 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Salida EQQUX014 Salida de operación dependiente del tiempo (EQQUX014) El controlador invoca EQQUX014 cuando una operación dependiente del tiempo pasa a estar preparada en un entorno z/OS. No es aplicable para operaciones planificadas en estaciones de trabajo distribuidas en un entorno global con tolerancia a fallos. La salida devuelve un desplazamiento, expresado en minutos, que se añadirá a la hora de inicio de la operación. El resultado lo utiliza la tarea del analizador de estación de trabajo para decidir si se puede iniciar la operación. La biblioteca de ejemplos SEQQSAMP contiene un ejemplo de salida EQQUX014. Describe la lógica de la salida, basada en una tabla de criterios a la que hace referencia el nombre UX14IN DD en el JCL de la tarea iniciada por el controlador. Utilice la tabla para correlacionar el nombre de estación de trabajo y el valor de desplazamiento. Opcionalmente, puede especificar reglas de filtrado para excluir operaciones seleccionadas del proceso que suma el valor de desplazamiento a la hora de inicio de la operación. El diseño siguiente define los rangos de columnas donde colocar datos de clave en el archivo UX14IN: 1-2 Tipo de datos. Especifique uno de los valores siguientes: WS Para correlacionar nombre de estación de trabajo y valor de desplazamiento. AD Para excluir una operación por el nombre de aplicación. IA Para excluir una operación por valor de llegada de entrada. OP Para excluir una operación por número de operación. JN Para excluir una operación por nombre de trabajo. 3 Un carácter en blanco (relleno). 4-19 Uno de los valores siguientes: v Nombre de estación de trabajo (hasta 4 caracteres) para tipo de datos de WS. Se da soporte al carácter comodín *. v Nombre de aplicación (hasta 16 caracteres) para tipo de datos de AD. Se da soporte al carácter comodín *. v Llegada de entrada (hasta 10 caracteres) para tipo de datos de IA. Utilice el formato AAMMDDHHMM. v Número de operación (hasta 3 caracteres) para tipo de datos de OP. v Nombre de trabajo (hasta 8 caracteres) para tipo de datos de JN. Se da soporte al carácter comodín *. 20 Signo (+ o -) sólo para tipo de datos de WS. 21-24 Valor de desplazamiento sólo para tipo de datos de WS. Cuando edite el archivo UX14IN, especifique los tipos siguientes en el siguiente orden específico: v Todas las filas con tipo de datos de WS en primer lugar. v v v v A continuación A continuación A continuación A continuación todas todas todas todas las las las las filas filas filas filas con con con con tipo tipo tipo tipo de de de de datos datos datos datos de AD (si las hay). de IA (si las hay). de OP (si las hay). de JN (si las hay). Puede añadir texto de comentario utilizando la serie /*. Capítulo 4. Salidas de Tivoli Workload Scheduler for z/OS 261 Salida EQQUX014 Consulte también la sección “Ejemplo” en la página 263. Para obtener más detalles, consulte el prólogo de la salida. La biblioteca de ejemplos SEQQSAMP creada durante la instalación contiene un ejemplo de salida EQQUX014. Para obtener información sobre esta biblioteca y sus ejemplos, consulte Apéndice C, “Biblioteca de ejemplos (SEQQSAMP)”, en la página 419. Instalación de la salida El módulo de carga que implementa esta salida se debe enlazar a una biblioteca autorizada por APF en la concatenación LNKLST o definida mediante la sentencia STEPLIB DD en el procedimiento de JCL del controlador. Si el módulo de carga realiza operaciones de entrada o salida, se debe enlazar con RMODE(24) según las restricciones normales de z/OS. Interfaz a la salida Cuando se especifica la salida, el registro 1 contiene la dirección de la lista de parámetros. Se utiliza cada una de las direcciones de esta lista para ubicar el valor del parámetro. Los siguientes son los parámetros que se pasan a la salida: Parámetros de EQQUX014 262 MCAUSERF TABPTR NUMROW RECSIZE ADID IATIME DS DS DS DS DS DS WSNAME JOBNAME OPNUM TOFFS DS DS DS DS RCODE DS A (Campo de usuario) A (Dirección de tabla de criterios) F (Número de filas del archivo de criterios) F (Tamaño de registro del archivo de criterios) CL16 (Nombre de la aplicación de la operación) CL10 (Hora de llegada de entrada de la operación, formato AAMMDDHHSS) CL4 (Nombre de la estación de trabajo de la operación) CL8 (Nombre de trabajo de la operación) F (Número de la operación) F (Desplazamiento que sumará a, o se restará de, la hora de inicio de la operación) F (Código de retorno) MCAUSERF Campo de usuario que también se pasa a la salida EQQUX000. El planificador para z/OS no utiliza ni actualiza este campo. TABPTR Campo de usuario que contiene la dirección de la tabla de criterios utilizada por esta salida. No es asignada por el planificador. La salida debe devolver un valor que se almacena en el almacenamiento del controlador y se devuelve a la salida en cada nueva llamada. Según el ejemplo proporcionado, la primera vez que se invoca la salida, TABPTR se debe establecer en cero; las veces siguientes contiene la dirección de la tabla de criterios que utilizará la salida. NUMROW Campo de usuario que contiene el número de filas del archivo de criterios de entrada. La primera vez que se invoca la salida, ésta debe establecer y devolver este valor, que se almacena en el almacenamiento del controlador y se devuelve a la salida en cada nueva llamada. RECSIZE Campo de usuario que contiene el tamaño de registro del archivo de criterios de entrada. La primera vez que se invoca la salida, ésta IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Salida EQQUX014 debe establecer y devolver este valor, que se almacena en el almacenamiento del controlador y se devuelve a la salida en cada nueva llamada. ADID Nombre de la aplicación de la que forma parte el trabajo que está pasando a preparado. IATIME Hora de llegada de entrada del trabajo que está pasando a preparado. WSNAME Nombre de la estación de trabajo definida para el trabajo que está pasando a preparado. JOBNAME Nombre del trabajo que está pasando a preparado. OPNUM Número de la operación del trabajo que está pasando a preparado. TOFFS Signo y valor del desplazamiento expresado en minutos que se sumará a la hora de inicio del trabajo. Este parámetro lo utiliza la tarea del analizador de estación de trabajo para decidir si la operación se puede iniciar o no. El controlador utiliza el desplazamiento devuelto para actualizar sólo la hora de inicio del trabajo. El proceso deja sin modificar la última hora de inicio. El miembro de ejemplo EQQUX014 utiliza una tabla de criterios para calcular este desplazamiento; sin embargo, puede establecerlo utilizando un método distinto. RCODE Código de retorno establecido por la salida. Un valor distinto de 0 indica que el planificador ha desactivado la salida. Ejemplo Suponga que: v CPU1 es una estación de trabajo correspondiente a Roma que es la ubicación donde se ejecuta el controlador. v CPU2 es una estación de trabajo correspondiente a la ubicación de una sucursal en Estambul. v Hay dos estaciones de trabajo Z* adicionales, correspondientes a distintas ubicaciones de sucursales en Londres. Para especificar la información de desplazamiento y los criterios de selección, defina los datos siguientes en el conjunto de datos UX14IN: EDIT TWSTST.TWSIDD1.UX014 Columns 00001 00072 Command ===> Scroll ===> CSR =COLS> ----+----1----+----2----+----3----+----4----+----5----+----6----+----7-****** ***************************** Top of Data ****************************** 000101 WS CPU2 +0060 000102 WS Z* -0060 000103 /* TO EXCLUDE SPECIFIC OPERATIONS 000110 AD MYAPPLID 000120 JN JOBX123 000200 JN MYJOB ****** **************************** Bottom of Data **************************** Cuando la operación está preparada para iniciarse, el controlador invoca la salida y asigna los desplazamientos especificados a cualquier operación asociada con CPU2 o Z*, a menos que: v La operación pertenezca a MYAPPLID. v La operación esté definida con el nombre de trabajo JOBX123 o MYJOB. Capítulo 4. Salidas de Tivoli Workload Scheduler for z/OS 263 Salida EQQUX014 Limitaciones El controlador utiliza el valor TOFFS devuelto para actualizar la hora de inicio del trabajo y deja sin modificar la última hora de inicio. Esto podría afectar a las actividades más recientes relacionadas con hora de inicio, como por ejemplo: v El proceso de la opción SUPPRESS IF LATE. v Condiciones de alerta o supervisión de trabajos críticos. Por ejemplo, considere un trabajo que tiene 9:00 como hora de inicio y 9:30 como la última hora de inicio. Suponiendo que la salida devuelva +0060 como TOFFS, el trabajo pasa a tener retardo tan pronto como está preparado para iniciarse. Salida de catálogo EQQDELDS/EQQCLEAN (EQQUXCAT) El programa EQQDELDS o EQQCLEAN de ejemplo invoca la salida EQQUXCAT antes de realizar cualquier acción de limpieza simple. Debido a que en algunos casos es posible que EQQCLEAN suprima un conjunto de datos por error, se recomienda que proteja los conjuntos de datos críticos frente a una supresión utilizando los parámetros RCLOPTS (DDPROT, DDPRMEM, DSNPROT, DSNPRMEM) o la salida de EQQUXCAT. EQQDELDS y EQQCLEAN no realizan la acción cuando el código de retorno se establece en un valor distinto de cero. La biblioteca de ejemplos SEQQSAMP creada durante la instalación contiene la salida EQQUXCAT, que es un ejemplo de salidas EQQDELDS/EQQCLEAN. Para obtener información sobre esta biblioteca y sus ejemplos, consulte Apéndice C, “Biblioteca de ejemplos (SEQQSAMP)”, en la página 419. Instalación de la salida El módulo de carga que implementa la salida se debe enlazar a una biblioteca autorizada por APF visible al ejemplo EQQDELDS (por ejemplo, la sentencia STEPLIB DD en el procedimiento EQQDELDS). Debe utilizar los atributos RMODE(24) y AMODE(31). Interfaz a la salida Se invoca la salida en modalidad de tarea, estado de problema y clave 8 y la tarea de paso de trabajo está autorizada por APF. La salida debe restaurar este estado antes de volver a al emisor de la llamada. Se pasa el control a la salida utilizando la instrucción BAL. La salida se debe devolver al emisor de la llamada utilizando la dirección y la modalidad de direccionamiento pasadas a éste, normalmente el registro 14. Cuando se especifica la salida, el registro 1 contiene la dirección de la lista de parámetros. Se utiliza cada una de las direcciones de esta lista para ubicar el valor del parámetro. Los siguientes son los parámetros que se pasan a la salida: Parámetros de EQQUXCAT PDSNAME PMIGR PVSAM PTAPE PRETCOD DS DS DS DS DS CL44 CL1 CL1 CL1 F (nombre de conjunto de datos) (Y=conjunto de datos MIGRADO N=en caso contrario) (Y=conjunto de datos de VSAM N=en caso contrario) (Y=cinta N=en caso contrario) (código de retorno) Nota: Si se devuelve un código de retorno distinto de 0, la acción del conjunto de datos no se ejecutará. 264 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Salida EQQUXGDG Salida de resolución de GDG de EQQCLEAN (EQQUXGDG) El programa EQQCLEAN invoca EQQUXGDG inmediatamente antes de ejecutar cualquier acción de sobrescritura de GDG en bloques de control de JES. Puede utilizar esta salida para impedir la sobrescritura de GDG, es decir, evitar la sustitución de un número relativo con un formato absoluto de GDG (GDGRoot.GnnnnVnn). EQQCLEAN no ejecutará la acción cuando el código de retorno de EQQUXGDG se establece en un valor distinto de 0. Tenga en cuenta que EQQUXGDG sólo puede impedir la simulación de un GDG, no su supresión. Para impedir la supresión de un GDG, utilice la salida EQQUXCAT o las sentencias DDPROT, DSNPROT RCLOPTS. Por este motivo, si desea coordinar las acciones de supresión y simulación (por ejemplo, no simular conjuntos de datos que se han protegido de la supresión), debe hacer lo siguiente: v Utilice la misma lógica para EQQUXCAT y EQQUXGDG. v Añada a EQQUXGDG la lógica para leer tablas que contengan la lista de nombres DDPROT y DSNPROT, de forma que EQQUXGDG pueda decidir no simular un GDG si se encuentra su DD o DSN en estas tablas. Por ejemplo, suponga que ejecuta un JCL con el paso siguiente: //STEP1 EXEC PGM=MYPGM //DDPRO1 DD DSN=MYGDG.TEST(+1),DISP=(NEW,CATLG) La primera ejecución ha asignado el conjunto de datos MYGDG.TEST.G0015V00. Si desea volver a ejecutar este JCL, guardando el GDG G00015V00 asignado anteriormente y asignando una nueva generación G00016V00, puede hacer lo siguiente: 1. Defina DDPRO1 en la sentencia del controlador DDPROT RCLOPTS. 2. Personalice EQQUXGDG para que no simule el conjunto de datos que tiene DDNAME igual a DDPROT. De forma opcional, puede hacer lo siguiente: 1. Personalice EQQUXCAT para que no suprima el conjunto de datos que empieza con MYGDG.TEST y el DD name DDPROT. 2. Personalice EQQUXGDG para que no simule el conjunto de datos que empieza con MYGDG.TEST y el DD name DDPROT. La biblioteca de ejemplos SEQQSAMP creada durante la instalación contiene la salida EQQUXGDG, que es un ejemplo de salidas EQQCLEAN. Para obtener información sobre esta biblioteca y sus ejemplos, consulte Apéndice C, “Biblioteca de ejemplos (SEQQSAMP)”, en la página 419. Interacciones de DDPROT/DSNPROT Puede proteger un conjunto de datos frente a su supresión estableciendo las opciones DDPROT y DSNPROT para la sentencia RCLOPTS en el controlador. Sin embargo, debe considerar las interacciones siguientes que estas tienen con las salidas EQQUXCAT y EQQUXGDG: v EQQUXCAT (salida de prevención de supresión) y EQQUXGDG (salida de prevención de simulación) pasan a estar activas tan pronto como están disponibles al programa EQQCLEAN en la biblioteca. Por el contrario, DDPROT y DSNPROT pasan a estar activas sólo después de que se emita un reinicio del controlador o un mandato MODIFY adecuado. Por este motivo, es posible que Capítulo 4. Salidas de Tivoli Workload Scheduler for z/OS 265 Salida EQQUXGDG para algunos trabajos las salidas EQQCLEAN apliquen una lógica basada en una denominación DDPROT/DSNPROT que difiera de la lógica normal de RCLOPTS. v La lógica de prevención de RCLOPTS DDPROT/DSNPROT se aplica a nivel de controlador, de forma que cuando se van a ejecutar las salidas EQQCLEAN, el controlador ya ha eliminado el conjunto de datos protegido de la lista de acciones. En este momento, si se invocan las salidas EQQCLEAN, EQQUXCAT sólo puede proteger frente a su supresión otros conjuntos de datos, pero no puede modificar los conjuntos de datos que ya están protegidos. Instalación de la salida El módulo de carga que implementa la salida se debe enlazar a una biblioteca autorizada por APF visible al programa EQQCLEAN (por ejemplo, la sentencia STEPLIB DD del procedimiento EQQCLEAN). Debe utilizar los atributos RMODE(24) y AMODE(31). Interfaz a la salida Se invoca la salida en modalidad de tarea, estado de problema y clave 8 y la tarea de paso de trabajo está autorizada por APF. La salida debe restaurar este estado antes de volver a al emisor de la llamada. Se pasa el control a la salida utilizando la instrucción BAL. La salida se debe devolver al emisor de la llamada utilizando la dirección y la modalidad de direccionamiento pasadas a éste, normalmente el registro 14. Cuando se especifica la salida, el registro 1 contiene la dirección de la lista de parámetros. Se utiliza cada una de las direcciones de esta lista para ubicar el valor del parámetro. Los siguientes son los parámetros que se pasan a la salida: Parámetros de EQQUXGDG PJOBNAM PSTEPNUM PSTEPNAM PPROCSTE PDDNAME PROOT PABSOLUT PSIGN PRELNUM PRETCODE 266 DS DS DS DS DS DS DS DS DS DS CL8 CL3 CL8 CL8 CL8 CL35 CL8 CL1 CL7 F (nombre del trabajo) (número de paso) (nombre del paso) (nombre del paso de proceso) (DD name) (raíz de GDG) (valor absoluto de GDG) (signo de número relativo de GDG) (número relativo de GDG) (código de retorno) PJOBNAM Nombre del trabajo del JCL que se ejecutará. PSTEPNUM Número de paso (expresado en formato de caracteres) donde se encuentra el conjunto de datos de GDG que se sobrescribirá. PSTEPNAM Nombre del paso donde se encuentra el conjunto de datos de GDG que se sobrescribirá. PPROCSTE Nombre del paso de proceso donde se encuentra el conjunto de datos de GDG que se sobrescribirá. PDDNAME Nombre DD donde se encuentra el conjunto de datos de GDG que se sobrescribirá. PROOT Raíz de GDG del conjunto de datos de GDG que se sobrescribirá. IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Salida EQQUXGDG PABSOLUT Valor absoluto (GnnnnVnn) que se utilizará para sobrescribir el conjunto de datos de GDG de entrada. PSIGN Signo (+ o – o en blanco) del número relativo del conjunto de datos de GDG que se sobrescribirá. PRELNUM Número relativo (expresado en formato de caracteres) del conjunto de datos de GDG que se sobrescribirá. PRETCOD Código de retorno establecido por la salida: 0 significa ejecutar la sobrescritura, 4 significa no ejecutar la sobrescritura. Salida de incorporación de JCL Puede utilizar la salida de incorporación de JCL para incluir JCL en la secuencia de trabajos actual cuando se configure o envíe el trabajo. La salida la invoca la directiva FETCH en la sentencia //*%OPC JCL. El manejo de JCL y las directivas de Tivoli Workload Scheduler for z/OS se describen más detalladamente en la publicación Managing the Workload Instalación de la salida El módulo de carga que implementa la salida de incorporación de JCL se debe enlazar a una biblioteca autorizada por APF en la concatenación LNKLST o definida mediante la sentencia STEPLIB DD en la tarea iniciada de Tivoli Workload Scheduler for z/OS. El módulo de carga se puede enlazar con el atributo AMODE 24 o AMODE 31. Tivoli Workload Scheduler for z/OS invoca la salida en la modalidad de direccionamiento definida por el módulo de carga de salida. Interfaz a la salida La salida de incorporación de JCL se invoca en modalidad de tarea, estado de problema y clave 8. La tarea de paso de trabajo está autorizada por APF. La tarea activa se ejecuta con la misma autorización de acceso que la tarea de paso de trabajo. La salida debe restaurar este estado antes de volver a al emisor de la llamada. Se invoca la salida utilizando la instrucción BASSM y se debe devolver a al emisor de la llamada utilizando la dirección y la modalidad de direccionamiento pasada a la misma, en general el registro 14. El método recomendado es restaurar todos los registros a sus valores en la entrada a la salida y devolver al emisor de la llamada utilizando una instrucción BSM 0,14. Si la salida se especifica como AMODE 31, debe cambiar a AMODE 24 antes de realizar cualquier operación de entrada o salida y, a continuación, volver a cambiar a AMODE 31 antes de volver al emisor de la llamada. Si la salida termina anormalmente, se marca como no ejecutable, y se emite el mensaje EQQJ616E. Tivoli Workload Scheduler for z/OS no intenta invocar de nuevo la salida. Los parámetros pasados a la salida se encuentran por debajo de la línea de 16 MB. Además, las direcciones pasadas a la salida son direcciones de áreas por debajo de la línea de 16 MB. Capítulo 4. Salidas de Tivoli Workload Scheduler for z/OS 267 Salida de incorporación de JCL Cuando se especifica la salida, el registro 1 contiene la dirección de la lista de parámetros. Se utiliza cada una de las direcciones de esta lista para ubicar el valor del parámetro. Los siguientes son los parámetros que se pasan a la salida: Parámetros de salida de incorporación de JCL JOBNAME DS IOAREA DS IOAREAL DS DATAL DS ADID DS WSDP DS OCCP DS OPRP DS WEEKD DS WEEKY DS RC DS MCAUSERF DS 268 CL8 A F F CL16 A A A CL1 CL2 F A (Nombre del trabajo) (Dirección del área de almacenamiento intermedio de JCL) (Tamaño del área de almacenamiento intermedio de JCL) (Cantidad de datos devueltos) (Nombre de la aplicación actual) (Dirección de datos de la estación de trabajo) (Dirección de datos de la aparición) (Dirección de datos de la operación) (Día de la semana: 1-7, donde 1 es lunes) (Semana del año) (Código de retorno) (Dirección establecida por el usuario en la salida EQQUX000) JOBNAME Nombre del trabajo que se va a enviar. IOAREA Dirección de un almacenamiento intermedio, asignado por IBM Tivoli Workload Scheduler for z/OS, donde se deben colocar los registros de JCL para el trabajo actual. Los registros de JCL se deben colocar de forma consecutiva en este almacenamiento intermedio sin ningún espacio entre ellos. IOAREAL Cantidad de espacio, en bytes, en el almacenamiento intermedio de IOAREA. En la implementación actual, este valor es siempre 32768 para cada llamada a la salida. Existe espacio suficiente para devolver hasta 409 imágenes de tarjeta de JCL para cada llamada a la salida. DATAL Cantidad de datos devuelta por la salida. No puede ser un valor negativo ni un valor mayor que el valor de IOAREAL. Un valor de cero es válido en la última llamada. ADID Nombre de la aplicación actual. WSDP Dirección de los datos de la estación de trabajo. El almacenamiento de esta dirección se correlaciona mediante el segmento de la interfaz de programa (PIF) WSCOM. OCCP Dirección de los datos de la aparición. El almacenamiento de esta dirección se correlaciona mediante el segmento CPOC de PIF. OPRP Dirección de los datos de la operación. El almacenamiento en esta dirección se correlaciona mediante un segmento CPOP de PIF. WEEKD Día de la semana en el que se invoca la salida. Es un valor numérico de 1 a 7, donde 1 es lunes. WEEKY Número de la semana actual del año actual. Es un valor numérico de 1 a 53, y se calcula según el estándar internacional ISO 8601. Este estándar utiliza un ciclo de cinco valores de “semana del año” para determinar en qué semana cae el primero de enero. El ciclo es 53, 52, 1, 1, 1. El ciclo inicial se inició en 1988. Es decir, el 1 de enero de 1988 era la semana 53 de 1987. El 1 de enero de 1989 fue la semana 52 de 1988 y el 1 de enero de 1990 era la semana 1 de 1990. IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Salida de incorporación de JCL RC MCAUSERF Código de retorno establecido por la salida. Son válidos los valores siguientes: 0 Retorno normal. La cantidad de datos devuelta por la última llamada a la salida se proporciona en DATAL. Se invocará de nuevo la salida para devolver más registros de JCL para el trabajo actual. La cantidad total de datos devueltos por la salida debe ser inferior a 256 KB. Consta de 3276 registros de JCL. 4 Fin de los datos alcanzado por el trabajo actual. La cantidad de datos devuelta por la última llamada a la salida se proporciona en DATAL. No se invocará de nuevo la salida para el trabajo actual. 8 No se ha podido encontrar el trabajo en ningún conjunto de datos de entrada. No se invocará de nuevo la salida para el trabajo actual. Campo de usuario que permite asignar recursos en la salida de inicio/detención, EQQUX000, que esta salida puede utilizar posteriormente. Este campo contiene el valor establecido por la salida EQQUX000. IBM Tivoli Workload Scheduler for z/OS no utiliza ni actualiza este campo. Salida de sustitución de variables (en la variable de definición de trabajos o JCL) Cuando define una variable de JCL o una variable de definición de trabajo, puede especificar el nombre de la salida que se invocará cuando sea necesaria la sustitución de la variable. Se puede invocar la salida en distintas fases en función de lo que envíe: v Si envía un trabajo contenido en la biblioteca de trabajos, se invoca la salida durante la configuración o el envío del trabajo, pero no se invoca para variables de configuración con indicador de solicitud. v Si envía una definición de trabajo contenida en la biblioteca SCRPTLIB, se invoca la salida durante el proceso de análisis de la definición de trabajo; es decir, cuando añade una aparición desde el diálogo MCP o cuando ejecuta una tarea (un plan diario, una replanificación o una renovación de Symphony) que da como resultado la generación de un archivo Symphony. Puede utilizar la salida para proporcionar el valor de una variable. Para obtener más información sobre variables de JCL, consulte la publicación IBM Tivoli Workload Scheduler for z/OS Managing the Workload. La biblioteca de ejemplos SEQQSAMP creada durante la instalación contiene la salida EQQJVXIT, que es un ejemplo de salidas de sustitución de variables. Para obtener información sobre este ejemplo, consulte “Salida de sustitución de variables de JCL” en la página 426. Instalación de la salida El módulo de carga que implementa la salida de sustitución de variables de JCL se debe enlazar a una biblioteca en la concatenación LNKLST o definida mediante la sentencia STEPLIB DD del procedimiento de JCL de controlador. Si se utiliza la salida para miembros del SCRPTLIB, la sentencia STEPLIB DD de los trabajos de JCL para la ampliación de plan diario, replanificación de plan diario y renovación de Symphony debe apuntar a la biblioteca que la contiene. El módulo de carga se Capítulo 4. Salidas de Tivoli Workload Scheduler for z/OS 269 Salida de sustitución de variables puede enlazar con el atributo AMODE 24 o AMODE 31. Tivoli Workload Scheduler for z/OS invoca la salida en la modalidad de direccionamiento definida por el módulo de carga de salida. Interfaz a la salida Se invoca la salida de sustitución de variables de JCL en modalidad de tarea, estado de problema y clave 8 y la tarea de paso de trabajo está autorizada por APF. La tarea activa se ejecuta con la misma autorización de acceso que la tarea de paso de trabajo. La salida debe restaurar este estado antes de volver a al emisor de la llamada. Se invoca la salida utilizando la instrucción BASSM y se debe devolver a al emisor de la llamada utilizando la dirección y la modalidad de direccionamiento pasada a la misma, en general el registro 14. El método recomendado es restaurar todos los registros a sus valores en la entrada a la salida y devolver al emisor de la llamada utilizando una instrucción BSM 0,14. Si la salida se especifica como AMODE 31, debe cambiar a AMODE 24 antes de realizar cualquier operación de entrada o salida y, a continuación, volver a cambiar a AMODE 31 antes de volver al emisor de la llamada. Si la salida termina anormalmente, se marca como no ejecutable y se emite el mensaje EQQJ518E. Tivoli Workload Scheduler for z/OS no intenta invocar de nuevo la salida. Todos los parámetros pasados a la salida se encuentran por debajo de la línea de 16 MB. Además, las direcciones pasadas a la salida son direcciones de áreas por debajo de la línea de 16 MB. Cuando se especifica la salida, el registro 1 contiene la dirección de la lista de parámetros. Se utiliza cada una de las direcciones de esta lista para ubicar el valor del parámetro. Los siguientes son los parámetros que se pasan a la salida: Parámetros de la salida de sustitución de variables VARNAME VARTAB VARLGTH VARDEF DS CL8 DS CL16 DS F DS CL44 VARNVAL DS CL44 VAROPRP DS A VARWSP DS A VAROCCP DS A VARDWEEK DS CL1 VARWEEKY DS CL2 VARRETC DS F MCAUSERF DS A VARJCL DS VARFIRST DS VARLINES DS VARUFLN DS VARUFLB DS VARNAME 270 CL80 A F F A (Nombre de variable para sustitución) (Nombre de tabla de variables de JCL) (Longitud necesaria de valor de variable) (Valor predeterminado de variable tal y como está definido en la tabla) (Valor de variable, establecido por la salida) (Dirección de datos de la operación) (Dirección de datos de la estación de trabajo) (Dirección de datos de la aparición) (Día de la semana: 1-7, donde 1 es lunes) (Semana del año) (Código de retorno, establecido por la salida) (Dirección establecida por el usuario en la salida EQQUX000) (Línea de JCL actual donde se ha encontrado esta variable) (Dirección de la primera línea de JCL para el trabajo) (Número de líneas de JCL en el trabajo) (Número de campos de usuario) (Dirección del almacenamiento intermedio de los campos de usuario) Nombre de la variable para la sustitución. IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Salida de sustitución de variables VARTAB Nombre de la tabla de variables de JCL. VARLGTH Longitud necesaria del valor de la variable o X'00' si no hay definida ninguna longitud para la variable. VARDEF Valor predeterminado de la variable tal y como está definido en la tabla de variables, justificado a la izquierda y rellenado con X'40'. VARNVAL valor de la variable establecida por la salida. VAROPRP Dirección de datos de la operación. El almacenamiento en esta dirección se correlaciona mediante el segmento CPOP de la interfaz de programa (PIF). VARWSP Dirección de datos de la estación de trabajo. El almacenamiento en esta dirección se correlaciona mediante el segmento WSCOM de PIF. VAROCCP Dirección de los datos de la aparición. El almacenamiento de esta dirección se correlaciona mediante el segmento CPOC de PIF. VARDWEEK Día de la semana en el que se invoca la salida. Es un valor numérico de 1 a 7, donde 1 es lunes. VARWEEKY Número de la semana actual del año. Es un valor numérico de 1 a 53 y se calcula según el estándar internacional ISO 8601. VARRETC Código de retorno establecido por la salida. Son válidos los valores siguientes: 0 Proceso de variable normal. 8 Se detiene la personalización. Si se invoca la salida al enviar el trabajo, la operación se establece como finalizada con error. Si se ha invocado durante la configuración mediante los diálogos en línea, se emite un mensaje de error en el terminal. MCAUSERF Campo de usuario que permite asignar recursos en la salida de inicio/detención, EQQUX000, que esta salida puede utilizar posteriormente. Este campo contiene la dirección que se establece en EQQUX000. Tivoli Workload Scheduler for z/OS no utiliza ni actualiza este campo. VARJCL Línea de JCL donde se ha encontrado esta variable. Se establece en caracteres en blanco si está enviando una definición de trabajo que contiene la biblioteca SCRPTLIB. VARFIRST Dirección de la primera línea de JCL. Se establece en cero si está enviando una definición de trabajo que contiene la biblioteca SCRPTLIB. VARLINES Número de líneas de JCL. Se establece en cero si está enviando una definición de trabajo que contiene la biblioteca SCRPTLIB. VARUFLN El número de registros de campos de usuario en USRFAREA. VARUFLB Dirección del área del campo de usuario. Se distribuye del modo siguiente: Capítulo 4. Salidas de Tivoli Workload Scheduler for z/OS 271 Salida de sustitución de variables USRFAREA USRFNAME DS USRFVAL DS CL16 CL54 (Nombre del campo de usuario) (Valor del campo de usuario) Notas: 1. No se invoca la salida para variables de JCL de configuración definidas con indicador de solicitud. 2. Si un valor se establece en el campo VARNVAL, Tivoli Workload Scheduler for z/OS lo utiliza sólo si VARRETC es cero. 3. El valor devuelto a Tivoli Workload Scheduler for z/OS en el campo VARNVAL debe cumplir las reglas de verificación definidas para la variable. 4. El valor de la variable se toma de los datos del campo VARNVAL hasta el primer X'40'. Salida de recuperación automática de trabajos Las sentencias de control de la recuperación automática pueden incluir el parámetro de recreación de JCL CALLEXIT. Éste especifica el nombre de un módulo de salida de programa que se invoca antes del reinicio. Se invoca la salida para cada línea de JCL que empieza con el primer registro del archivo de JCL. La salida puede decidir aceptar, modificar o suprimir la línea; o bien insertar una o más líneas. La rutina de salida también puede impedir el reinicio o terminar la recuperación automática. Consulte la publicación Managing the Workload para obtener más información sobre la recuperación automática de trabajos y tareas iniciadas. Instalación de la salida El módulo de carga que implementa la salida de recuperación automática de trabajos se debe enlazar a una biblioteca autorizada por APF en la concatenación LNKLST o definida mediante la sentencia STEPLIB DD en el procedimiento de JCL de Tivoli Workload Scheduler for z/OS. Si el módulo de carga realiza alguna operación de entrada o salida, se debe enlazar con RMODE(24) según las restricciones normales de z/OS. O se puede enlazar con RMODE(ANY). Tivoli Workload Scheduler for z/OS invoca la salida en AMODE 31; el parámetro AMODE especificado cuando se enlazó no tiene ningún efecto. Interfaz a la salida Se invoca la salida de recuperación automática de trabajos en modalidad de tarea, estado de problema y clave 8, y la tarea de paso de trabajo está autorizada por APF. La tarea activa se ejecuta con la misma autorización de acceso que la tarea de paso de trabajo. La salida debe restaurar este estado antes de volver a al emisor de la llamada. Se pasa el control a la salida utilizando la instrucción BAL. La salida se debe devolver al emisor de la llamada utilizando la dirección y la modalidad de direccionamiento pasadas a éste, normalmente el registro 14. La salida se especifica en AMODE 31 pero se debe cambiar a AMODE 24 antes de realizar cualquier operación de entrada o salida y, a continuación, volver a cambiar a AMODE 31 antes de volver al emisor de la llamada. 272 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Salida de recuperación automática de trabajos Si la salida termina anormalmente, se marca como no ejecutable; Tivoli Workload Scheduler for z/OS no intenta invocar de nuevo la salida. Cuando se especifica la salida, el registro 1 contiene la dirección de la lista de parámetros. Se utiliza cada una de las direcciones de esta lista para ubicar el valor del parámetro. Los siguientes son los parámetros que se pasan a la salida: Parámetros de la salida de recuperación automática de trabajos REC S PS JC SC UF IND RC DS CL80 (Registro de JCL) DS CL8 (Nombre de paso fallido, o en blanco si el error no está asociado con un paso) DS CL8 (Nombre de paso fallido en procedimiento, o en blanco) DS CL4 (Código de retorno o código de error de trabajo) DS CL4 (Código de retorno o código de error de paso fallido, en blanco si el error no está asociado con un paso) DS F (Campo de usuario, la primera vez es cero) DS F (Indicador: 0 Primer registro 1 Otro registro distinto del primero 2 No más registros en archivo) DS F (Código de retorno) Los campos S y PS contienen espacios en blanco si se ha producido un error en la fase de inicialización o finalización del trabajo. Los campos también están en blanco si no hay ningún nombre en la sentencia EXEC. El código de retorno que establecerá la salida (RC) depende del valor de IND. Para IND=0 y IND=1, los valores de RC (que se proporcionan como dígitos hexadecimales) tienen el significado siguiente: 00 Guarda el registro (posiblemente actualizado) y devuelve el siguiente. 04 Inserta el registro (uno nuevo en REC) y devuelve el mismo registro que la última vez. 08 Suprime el registro y devuelve el siguiente. 0C No es necesaria inspección adicional. Actualiza el archivo de JS y continúa las acciones de recuperación para este trabajo. 10 Termina las acciones de recuperación para este trabajo después de actualizar el archivo de JS. 14 Termina las acciones de recuperación para este trabajo sin actualizar el archivo de JS. Para IND=2, los valores de RC (que se proporcionan como dígitos hexadecimales) tienen el significado siguiente: 00 No válido. 04 Inserta el registro (uno nuevo en REC) y devuelve el control. 08 No válido. 0C No es necesaria inspección adicional. Actualiza el archivo de JS y continúa las acciones de recuperación para este trabajo. 10 Termina las acciones de recuperación para este trabajo después de actualizar el archivo de JS. Capítulo 4. Salidas de Tivoli Workload Scheduler for z/OS 273 Salida de recuperación automática de trabajos 14 Termina las acciones de recuperación para este trabajo sin actualizar el archivo de JS. Para inspeccionar todas las líneas de JCL antes de realizar cualquier cambio, copie las líneas de JCL en su propia área. Devuelva RC=08 hasta que se reciba IND=2. A continuación, modifique el JCL y devuelva las líneas una a una a Tivoli Workload Scheduler for z/OS con RC=04 especificado. Finalice devolviendo RC=0C. Salida de informe de planificación diaria (EQQDPUE1) Se invoca la salida de informe de planificación diaria (EQQDPUE1) mediante trabajos por lotes de planificación diaria de Tivoli Workload Scheduler for z/OS y se utiliza para manipular líneas de determinados informes de planificación diaria. Las líneas de los informes de planes de estación de trabajo y del plan operativo diario se pasan a la salida y se pueden procesar especialmente aquí. Puede utilizar la salida para añadir, suprimir o modificar líneas de estos informes. La salida es opcional. Instalación de la salida El módulo de carga que implementa la salida de informe de planificación diaria se debe enlazar a una biblioteca autorizada por APF en la concatenación LNKLST o definida mediante la sentencia STEPLIB DD en el procedimiento de JCL de Tivoli Workload Scheduler for z/OS. Si el módulo de carga realiza alguna operación de entrada o salida, se debe enlazar con RMODE(24) según las restricciones normales de z/OS. O se puede enlazar con RMODE(ANY). Tivoli Workload Scheduler for z/OS invoca la salida en AMODE 31; el parámetro AMODE especificado cuando se enlazó no tiene ningún efecto. Interfaz a la salida Se invoca la salida de informe de planificación diaria en modalidad de tarea, estado de problema y clave 8 y la tarea de paso de trabajo está autorizada por APF. La tarea activa se ejecuta con la misma autorización de acceso que la tarea de paso de trabajo. La salida debe restaurar este estado antes de volver a al emisor de la llamada. Se pasa el control a la salida utilizando la instrucción BAL. La salida se debe devolver al emisor de la llamada utilizando la dirección y la modalidad de direccionamiento pasadas a éste, normalmente el registro 14. La salida se especifica en AMODE 31 pero se debe cambiar a AMODE 24 antes de realizar cualquier operación de entrada o salida y, a continuación, volver a cambiar a AMODE 31 antes de volver al emisor de la llamada. Si la salida termina anormalmente, se marca como no ejecutable; Tivoli Workload Scheduler for z/OS no intenta invocar de nuevo la salida. Cuando se especifica la salida, el registro 1 contiene la dirección de la lista de parámetros. Se utiliza cada una de las direcciones de esta lista para ubicar el valor del parámetro. Los siguientes son los parámetros que se pasan a la salida: 274 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Salida EQQDPUE1 Parámetros de EQQDPUE1 REPTYPE DC REPLINE DC LINETYPE DC WSNAME DC LINEBACK DC ACTION DC H (Tipo de informe) CL121 (Línea de informe) H (Tipo de línea) CL4 (Nombre de WS (si REPTYPE=3)) CL121 (Línea a insertar desde la salida) H (Acción por línea) REPTYPE Tipo de llamada. Son válidos los valores siguientes: 1 Todos los informes finalizados (ninguna línea disponible en esta llamada) 2 Plan operativo diario 3 Plan de estación de trabajo. REPLINE Línea proporcionada a esta salida; tiene un máximo de 121 caracteres. Este parámetro especifica la línea que se debe imprimir. LINETYPE Especifica el tipo de línea que se debe imprimir. Son válidos los valores siguientes: 1 Subcabecera/su carácter de subrayado/cabecera de empresa 2 Sub-subcabecera/su carácter de subrayado 3 Línea de espacio (tipo ---------------) 4 Línea de espacio (tipo │ │ │ ) 5 Línea de datos 6 Línea en blanco. WSNAME Especifica el nombre de la estación de trabajo. Se utiliza sólo si REPTYPE=3; para los demás, permanece en blanco. LINEBACK Línea de salida; tiene un máximo de 121 caracteres. El primer carácter debe estar en blanco (tiene un carácter de control ASA). ACTION Especifica la acción para la línea. Son válidos los valores siguientes: 0 Línea no modificada 4 Línea modificada 8 Suprimir la línea 12 Insertar la línea antes la línea pasada 16 No invocar más; línea no modificada. Salida de validación de descripción de la aplicación (EQQUXPIF) El programa PIF invoca la salida de validación de descripción de la aplicación (EQQUXPIF) durante la actualización de la descripción de la aplicación (INSERT AD o REPLACE AD. Se utiliza para validar la descripción de la aplicación. La salida es opcional. Instalación de la salida El módulo de carga que implementa la salida de validación de descripción de la aplicación se debe enlazar a una biblioteca autorizada por APF definida por la sentencia STEPLIB DD del programa PIF actual. Esta salida la carga automáticamente el programa PIFsin que sea necesario indicar ningún parámetro. Tivoli Workload Scheduler for z/OS invoca la salida en AMODE 31; el parámetro AMODE especificado cuando se enlazó no tiene ningún efecto. Capítulo 4. Salidas de Tivoli Workload Scheduler for z/OS 275 Salida EQQUXPIF Interfaz a la salida Se invoca la salida de validación de descripción de la aplicación en modalidad de tarea, estado de problema y clave 8, y la tarea de paso de trabajo está autorizada por APF. La salida debe restaurar este estado antes de volver a al emisor de la llamada. Se pasa el control a la salida utilizando la instrucción BAL. La salida se debe devolver al emisor de la llamada utilizando la dirección y la modalidad de direccionamiento pasadas a éste, normalmente el registro 14. Cuando se especifica la salida, el registro 1 contiene la dirección de la lista de parámetros. Se utiliza cada una de las direcciones de esta lista para ubicar el valor del parámetro. Los siguientes son los parámetros que se pasan a la salida: Parámetros de EQQUXPIF REQUEST RESOURC RECLEN RECPTR RETCO ERRMSG DS DS DS DS DS DS CL8 CL8 F A F CL80 (Tipo de solicitud) (Tipo de recurso) (Longitud de registro) (Dirección de registro) (Código de retorno) (Serie del mensaje de error) REQUEST Tipo de solicitud de la base de datos (INSERT o REPLACE) RESOURC Tipo de recurso que se validará (AD). RECLEN Longitud del registro de base de datos que se validará (registro AD, consulte el diseño de DCLADR en la publicación IBM Tivoli Workload Scheduler for z/OS Diagnosis Guide and Reference). RECPTR Dirección del área de registro. Sólo puede estar validada. RETCO Código de retorno de la salida. Si su valor es mayor que 0, la actualización de la descripción de la aplicación (INSERT AD o REPLACE AD) falla y se visualiza un mensaje que contiene la serie ERRMSG. ERRMSG Mensaje que explica la razón de la anomalía de la actualización. El mensaje se visualiza sólo si RETCO es mayor que 0. Salida de usuario de System Automation for z/OS (EQQUXSAZ) Se invoca la salida de automatización del sistema EQQUXSAZ cada vez que se planifica una operación definida en una estación de trabajo general y automática, con la opción Automatización habilitada. La salida no puede modificar los parámetros recibidos ni otros datos o recursos de Tivoli Workload Scheduler for z/OS. EQQUXSAZ puede examinar los parámetros y realizar algunas acciones externas a Tivoli Workload Scheduler for z/OS en función de la información de los parámetros. Puede utilizar EQQUXSAZ para enviar la solicitud de mandato a System Automation forz/OS mediante la interfaz PPI de NetView. La biblioteca de ejemplos de Tivoli Workload Scheduler for z/OS creada durante la instalación contiene una salida EQQUXSAZ de ejemplo escrita en lenguaje ensamblador. Esta salida no envía el mandato a System Automation for z/OS, sólo recibe parámetros de entrada y los almacena en un área de variables local. Puede 276 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Salida EQQUXSAZ modificar la salida de ejemplo para crear su propio procedimiento de envío. Debe compilar y enlazar la salida de Tivoli Workload for z/OS sólo si ha personalizado la parte del envío. La salida EQQUXSAZ que realmente envía el mandato se proporciona con System Automation for z/OS. La encontrará definida en la biblioteca SINGMOD1 de System Automation for z/OS como un alias de EVJUXSAZ. Debe concatenar esa biblioteca en STEPLIB del procedimiento de inicio del controlador. Para obtener detalles sobre EQQUXSAZ de System Automation, consulte las publicaciones de System Automation for z/OS. Notas: 1. Tivoli Workload Scheduler for z/OS no realiza ninguna validación o comprobación de sintaxis de la solicitud que se direccionará a System Automation for z/OS. 2. En caso de tiempos de espera excedidos de System Automation, es posible que la operación se marque con el error OAUT en la parte de Tivoli Workload Scheduler for z/OS, incluso si se completa satisfactoriamente posteriormente en la parte de System Automation. 3. Para operaciones definidas en estaciones de trabajo de automatización, no se invoca la salida EQQUX007; sólo se invoca EQQUXSAZ. Instalación de la salida El módulo de carga que implementa la salida de automatización del sistema se debe enlazar a una biblioteca autorizada por APF en la concatenación LNKLST o definida mediante la sentencia STEPLIB DD en el procedimiento de JCL de Tivoli Workload Scheduler for z/OS. Si el módulo de carga realiza operaciones de entrada o salida, se debe enlazar con RMODE(24) según las restricciones normales de z/OS. Si el módulo de carga no realiza ninguna operación de entrada o salida, se puede enlazar con RMODE(ANY). Tivoli Workload Scheduler for z/OS invoca la salida en AMODE 31; el parámetro AMODE especificado cuando se enlazó no tiene ningún efecto. Interfaz a la salida La salida de automatización del sistema se invoca en modalidad de tarea, estado de problema y clave 8. La tarea de paso de trabajo está autorizada por APF. La tarea activa se ejecuta con la misma autorización de acceso que la tarea de paso de trabajo. La salida debe restaurar este estado antes de volver a al emisor de la llamada. Se pasa el control a la salida utilizando la instrucción BAL. La salida se debe devolver al emisor de la llamada utilizando la dirección y la modalidad de direccionamiento pasadas a éste, normalmente el registro 14. La salida se especifica en AMODE 31 pero se debe cambiar a AMODE 24 antes de realizar cualquier operación de entrada o salida. Antes de que la salida vuelva al emisor de la llamada, cámbiela de nuevo a AMODE 31. Cuando se especifica la salida, el registro 1 contiene la dirección de la lista de parámetros. Se utiliza cada una de las direcciones de esta lista para ubicar el valor del parámetro. Se pasan los parámetros siguientes a la salida: Capítulo 4. Salidas de Tivoli Workload Scheduler for z/OS 277 Salida EQQUXSAZ Parámetros de EQQUXSAZ ADNAME WSNAME WSDEST DS DS DS JOBNAME DS IA DS OPNUM DS COMMTEXT DS COMPINFO DS AUTFUNC DS SECELEM DS OWNER DS RETCODE DS 278 CL16 CL4 CL8 (Nombre de la aplicación) (Nombre de la estación de trabajo) (Nombre de destino de la estación de trabajo o dominio de NetView) CL8 (Nombre de trabajo de la operación) CL10 (Fecha y hora de llegada de entrada, formato AAMMDDHHMM) H (Número de operación) CL255 (Texto del mandato SA) CL64 (Información de terminación de SA) CL8 (Función automatizada de SA para la operación) CL8 (Elemento de seguridad de SA) CL16 (Nombre de propietario de la aplicación) F (Código de retorno) ADNAME Nombre de aplicación de la operación actual. WSNAME Nombre de la estación de trabajo para la operación actual WSDEST Destino de estación de trabajo definido por el usuario o dominio de NetView de destino. JOBNAME Nombre de trabajo definido para la operación actual. IA Fecha y hora de llegada de entrada para la operación actual, con el formato AAMMDDHHMM. OPNUM Número de operación para la operación actual. COMMTEXT Texto del mandato que se direccionará a System Automation. Tiene formato libre y puede obtener variables de Tivoli Workload Scheduler for z/OS que se sustituyen antes de que el mandato se pase a System Automation for z/OS. Si se produce un error durante esta fase, la operación se establece en E con el código OJCV. No se realiza ninguna comprobación de sintaxis del contenido del texto en el lado de Tivoli Workload Scheduler for z/OS. COMPINFO Información de terminación. Opcionalmente, puede especificar la siguiente información, en el orden siguiente, separada por una coma: v El tiempo máximo de espera, con el formato hh:mm:ss. Si se especifica, System Automation for z/OS espera la terminación del mandato durante el intervalo de tiempo especificado. Si el mandato no se completa, System Automation for z/OS envía la operación con error. v El código de retorno máximo aceptado como ejecución satisfactoria. Puede especificar el nombre de una rutina opcional de comprobación de terminación proporcionada por el usuario. La rutina de comprobación de terminación asegura que el mandato ha conseguido los resultados esperados, antes de enviar la operación como completada. AUTFUNC Función automatizada (para operación). Este parámetro es opcional. Si se especifica, el mandato se ejecuta en la tarea de NetView asociada con esta función automatizada en System Automation for z/OS. Puede utilizar este parámetro para serializar IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Salida EQQUXSAZ mandatos. Si no se especifica este parámetro, el mandato lo ejecuta cualquier tarea de NetView disponible. SECELEM Elemento de seguridad. Es un parámetro opcional utilizado para el seguimiento de seguridad de la operación. Puede utilizarlo como alternativa o conjuntamente con el nombre del trabajo, para validación de seguridad de la operación en el lado de System Automation for z/OS. OWNER Nombre del propietario de la operación actual. RETCODE Código de retorno máximo de la salida. El valor predeterminado es 0 (retorno normal, el proceso de Tivoli Workload Scheduler for z/OS continúa). Para ver una lista completa, consulte la publicación System Automation for z/OS Messages and Codes. Nota: Para la serie de texto del mandato (COMMTEXT) se permiten mayúsculas o minúsculas. Tivoli Workload Scheduler for z/OS cambia automáticamente a mayúsculas el valor especificado en COMPINFO, AUTOPER y SECELEM. Capítulo 4. Salidas de Tivoli Workload Scheduler for z/OS 279 Salida EQQUXSAZ 280 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Capítulo 5. Integración con Open Systems Puede utilizar el controlador para proporcionar un único punto de control coherente para enviar la carga de trabajo de cualquier entorno operativo y realizar un seguimiento de ésta. Tivoli Workload Scheduler for z/OS proporciona interfaces abiertas para permitir integrar la planificación y control de unidades de trabajo como por ejemplo transacciones en línea, transferencias de archivos o proceso por lotes en cualquier entorno operativo que pueda establecer comunicación con z/OS. En este capítulo se describe cómo utilizar Tivoli Workload Scheduler for z/OS para controlar la carga de trabajo en entornos operativos que no den soporte a un comprobador de seguimiento, mediante la salida de iniciación de operación, EQQUX009. Además, se proporciona un ejemplo de un método alternativo para controlar el proceso de VM. Control de sistemas heterogéneos Tivoli Workload Scheduler for z/OS proporciona interfaces abiertas para permitir enviar la carga de trabajo a, y notificar el estado de, cualquier entorno operativo que pueda establecer comunicación con z/OS. Cuando una operación en una estación de trabajo que especifica un ID de destino definido por el usuario está preparada para iniciarse, Tivoli Workload Scheduler for z/OS invoca la salida de iniciación de operación, EQQUX009. Se invoca la salida para operaciones en estaciones de trabajo de sistema que hayan cumplido los criterios de envío normales de Tivoli Workload Scheduler for z/OS para operaciones de trabajo o tarea iniciada. Se pasa información a la salida sobre la operación que se iniciará, el destino en el que se debe iniciar y, si está disponible, cualquier información equivalente de JCL de la biblioteca de trabajos (EQQJBLIB) o el archivo de configuración de trabajos (EQQJSxDS) de Tivoli Workload Scheduler for z/OS. La salida es responsable de transmitir los datos necesarios al destino. Existen varios métodos disponibles para transmitir datos a los distintos entornos operativos y para notificar el estado de la operación de nuevo al controlador. Por ejemplo, podría utilizar APPC/MVS, TCP/IP o NetView FTP. Una de las salidas de ejemplo proporcionada utiliza TCP/IP para comunicar los mandatos a un entorno OS/2. La biblioteca de ejemplos SEQQSAMP contiene ejemplos que muestran cómo puede utilizar Tivoli Workload Scheduler for z/OS para comunicarse con sistemas heterogéneos. v EQQOS2TR y EQQX9OS2 proporcionan programas de ejemplo para comunicarse con un entorno OS/2 para iniciar mandatos y notificar el estado de nuevo al controlador. v EQQCMV2 y EQQUX09N permiten planificar y controlar la carga de trabajo de VM definiendo operaciones exactamente como lo haría para la carga de trabajo de z/OS. v EQQAIXTR y EQQX9AIX proporcionan programas de ejemplo para comunicarse con un entorno AIX para iniciar tareas o emitir mandatos y notificar el estado de © Copyright IBM Corp. 1991, 2011 281 Control de sistemas heterogéneos vuelta al controlador. Este ejemplo se ha desarrollado y probado en un entorno AIX pero se puede trasladar a cualquier entorno UNIX que utilice un script de shell compatible. Apéndice C, “Biblioteca de ejemplos (SEQQSAMP)”, en la página 419 contiene descripciones de todos los ejemplos distribuidos con Tivoli Workload Scheduler for z/OS. La notificación del estado para las operaciones en destinos definidos por el usuario se consigue utilizando el mandato OPSTAT en TSO nativo, en una CLIST o REXX EXEC, o en SYSIN al programa EQQEVPGM, o invocando la subrutina EQQUSIN o EQQUSINT. Las estaciones de trabajo que especifican un destino definido por el usuario se inicializan con un estado desconocido cuando se inicia el controlador. La instalación es responsable de establecer la estación de trabajo en estado activo. La notificación de estado para la estación de trabajo se consigue utilizando el mandato WSSTAT en TSO nativo, en una CLIST o REXX EXEC, o en SYSIN para el programa EQQEVPGM, o invocando la subrutina EQQUSIN o EQQUSINW. La lógica para establecer el estado de la estación de trabajo en activo no debe estar en EQQUX009, ya que no se invoca nunca la salida cuando el estado es fuera de línea. Debe considerar utilizar la salida de inicio/detención EQQUX000 para establecer el estado de la estación de trabajo para destinos definidos por el usuario. El miembro de la biblioteca de ejemplos EQQUX0N invoca la subrutina EQQUSINW para establecer el estado de una estación de trabajo. Consulte “Salida de inicio o detención” en la página 422 para obtener más información sobre el ejemplo EQQUX0N. Configuración del entorno Debe realizar los pasos siguientes para habilitar el envío y seguimiento de un entorno determinado: 1. Seleccione un ID de destino exclusivo para representar el entorno de destino. 2. Defina el destino en la palabra clave USER de la sentencia ROUTOPTS. 3. Cree una descripción de estación de trabajo en el diálogo de Tivoli Workload Scheduler for z/OS. El tipo de estación de trabajo debe ser sistema con informe automático. 4. Escriba el código necesario para dar soporte al entorno: v EQQUX009. v Un programa para recibir e iniciar los datos en el sistema de destino y notificar los cambios a Tivoli Workload Scheduler for z/OS. v Código para manejar el estado de la estación de trabajo. Considere invocar este proceso en la salida EQQUX000, que se invoca cuando se inicia Tivoli Workload Scheduler for z/OS. 5. Especifique CALL09(YES) en la sentencia EXITS. Puede utilizar los programas de ejemplo para el código. Para obtener más información, consulte: v Capítulo 6, “Notificación de sucesos a Tivoli Workload Scheduler for z/OS”, en la página 289 v “Salida de iniciación de la operación (EQQUX009)” en la página 254 282 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Control de sistemas heterogéneos v La publicación Managing the Workload para ver una descripción de los mandatos OPSTAT y WSSTAT. Envío y seguimiento de la carga de trabajo La publicación Managing the Workload contiene los detalles de cómo Tivoli Workload Scheduler for z/OS selecciona el trabajo que se enviará a estaciones de trabajo determinadas. A continuación se muestra un resumen del proceso de envío y seguimiento para operaciones en una estación de trabajo que tiene un ID de destino definido por el usuario: v Cuando se selecciona la operación como la siguiente operación que se enviará, el estado se establece en SU. Tivoli Workload Scheduler for z/OS invoca la salida EQQUX009 y proporciona los datos almacenados en los conjuntos de datos EQQJSxDS o EQQJBLIB. No es necesario que la información esté almacenada en estas bibliotecas; la salida puede localizar los datos en cualquier otro lugar o es posible que los datos se almacenen en el destino. v EQQUX009 transmite los datos al destino. Un código de retorno correcto de la salida dejará la operación con el estado SU hasta que cambie mediante las rutinas de seguimiento normales de Tivoli Workload Scheduler for z/OS (si el trabajo se ejecuta en z/OS y hay presentes un grabador de sucesos y un conjunto de datos de suceso) o mediante la interfaz OPSTAT. v Si la operación entra en un sistema en cola en el destino, esto se puede notificar a Tivoli Workload Scheduler for z/OS mediante el mandato OPSTAT con STATUS(Q). Tivoli Workload Scheduler for z/OS establecerá el estado de la operación en SQ. v Cuando la operación realmente se empieza a ejecutar, esto se notifica utilizando el mandato OPSTAT para STATUS(T). Tivoli Workload Scheduler for z/OS establecerá el estado de la operación en SS. v Se notifica la terminación utilizando el mandato OPSTAT para STATUS(C), si es normal, o STATUS(E), si es anómalo. Se recomienda que utilice la SEÑAL pasada a EQQUX009 como entrada a OPSTAT. La SEÑAL es un valor de 4 bytes generado automáticamente por Tivoli Workload Scheduler for z/OS cuando se selecciona la operación para ser planificada. La finalidad de la señal es facilitar a los usuarios de OPSTAT identificar de forma exclusiva una operación de Tivoli Workload Scheduler for z/OS. Método alternativo para controlar el proceso de VM En VM, algunos EXEC se deben ejecutar en secuencias determinadas, y se deben comprobar los resultados para asegurar que los EXEC se han completado satisfactoriamente. Es posible que este trabajo se repita a intervalos regulares. Además, es posible que algunas aplicaciones requieran que el proceso de VM se comunique o esté sincronizado con el proceso de z/OS. Por lo tanto, es necesario disponer de mecanismos de control de producción de VM que se correspondan con los existentes en z/OS. A continuación se muestra una forma de automatizar el control de las operaciones de VM: 1. Configure un trabajo de z/OS para enviar una solicitud a un usuario de VM AUTOLOG para ejecutar un EXEC; esto lo haría normalmente utilizando un enlace NJE-RSCS. Cuando se completa, el EXEC envía un trabajo de vuelta a z/OS, que emite un mandato OPSTAT para notificar a Tivoli Workload Scheduler for z/OS sobre el estado de la operación de VM. El primer trabajo de z/OS lo planifica Tivoli Workload Scheduler for z/OS de la misma forma que cualquier otra operación de estación de trabajo de sistema. Capítulo 5. Integración con Open Systems 283 Método alternativo para controlar el proceso de VM 2. Configure una segunda operación para representar la ejecución del VM EXEC. Debe definir la operación en una estación de trabajo general con el atributo de informe automático, que se configura para este fin. Ésta es la operación cuyo estado cambia el mandato OPSTAT emitido por VM. Puede utilizar este método para planificar, controlar y realizar un seguimiento de la carga de trabajo de varios usuarios de VM en sitios locales y remotos. Este método no utiliza ninguna salida de Tivoli Workload Scheduler for z/OS ni requiere otros esfuerzos de programación. El miembro de la biblioteca de ejemplos EQQCVM se mantiene para instalaciones que han implementado este método en OPC/A o releases anteriores de Tivoli Workload Scheduler for z/OS. Método de uso Se proporciona un ejemplo para controlar la carga de trabajo de VM de Tivoli Workload Scheduler for z/OS en el archivo de ejemplo en el nombre de miembro EQQCVM. El miembro de ejemplo incluye las partes siguientes: v Sentencias de control del cargador de procesos por lotes para definir una descripción de la aplicación para ejecutar un trabajo de VM. v Un ejemplo de JCL para indicar a VM que se va a iniciar un trabajo. v Un CMS EXEC denominado OPCWATCH, que se ejecuta en el usuario de AUTOLOG VM. OPCWATCH recibe la señal de inicio de z/OS y dirige el EXEC solicitado en VM. v Un CMS EXEC denominado OPCSTAT, que puede utilizar OPCWATCH para indicar el cambio de estado del trabajo de VM a Tivoli Workload Scheduler for z/OS. Para utilizar Tivoli Workload Scheduler for z/OS para dirigir operaciones de VM, siga los pasos siguientes: 1. Defina una nueva estación de trabajo de Tivoli Workload Scheduler for z/OS, por ejemplo, VM, como una estación de trabajo general con un atributo de informe automático. La ventaja de tener una estación de trabajo aparte es que se pueden generar listas de preparados e informes distintos para operaciones de VM basados en el nombre de la estación de trabajo. 2. Defina una aplicación VMJJJJ con las operaciones siguientes: CPU1 010 JOBNAME RJJJJ VM 020 JOBNAME JJJJ ’SEND START ORDER TO VM’ ’TRACKS REAL EXECUTION OF EXEC’ El ciclo de ejecución y otras características deben ser los mismos que para las aplicaciones normales de z/OS. La figura siguiente muestra el miembro RJJJJ en la biblioteca de JCL de Tivoli Workload Scheduler for z/OS. Este JCL lo ejecutará la operación CPU1. 284 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Método alternativo para controlar el proceso de VM //RJJJJ JOB Job statement parameters according to // your installation standards /*JOBPARM CARDS=100 /*ROUTE PUNCH VMNODE.VMUSER //****************************************************************** //* //* A z/OS job to signal VM when the controlled job //* is ready to be started on the VM system. //* //****************************************************************** //B EXEC PGM=IEBGENER //SYSPRINT DD SYSOUT=Q //SYSUT1 DD * JJJJ /* //SYSUT2 DD SYSOUT=B //SYSIN DD DUMMY Figura 1. Miembro RJJJJ de la biblioteca de JCL de Tivoli Workload Scheduler for z/OS El primer registro de la secuencia de datos //SYSUT1 contiene el nombre del EXEC que se ejecutará, seguido por los parámetros que se deban pasar al EXEC. 3. Configure un usuario de VM AUTOLOG para esperar la llegada de cualquier archivo de lector. Puede utilizar un EXEC de espera para dirigir el usuario de VM AUTOLOG (por ejemplo, el OPCWATCH EXEC proporcionado en el miembro EQQCVM de la biblioteca de ejemplo de Tivoli Workload Scheduler for z/OS). Cuando los archivos de lector se envían a este usuario, éste procesa el EXEC especificado en los datos //SYSUT1. Los EXEC que se procesan se registran en el archivo OPCA LOG A. Nota: v Cada VM EXEC que se procesa debe establecer un código de retorno para indicar si se ha ejecutado satisfactoriamente. v El EXEC de espera depende del módulo WAKEUP para invocar su ejecución. El módulo WAKEUP está disponible en la distribución de VM/IPF. En la Figura 2 en la página 286 se muestra un ejemplo de control de operaciones de VM desde Tivoli Workload Scheduler for z/OS. En este ejemplo: 1. Tivoli Workload Scheduler for z/OS en ejecución en z/OS envía un EXEC denominado JJJJ a un usuario de VM, que está ejecutando el OPCWATCH EXEC. 2. OPCWATCH invoca otros dos VM EXEC, JJJJ y OPCSTAT. 3. Antes de después de que se procese JJJJ, OPCSTAT notifica el estado a una VM de estación de trabajo con información automática general de Tivoli Workload Scheduler for z/OS. 4. En MVS, los trabajos de VM ejecutan un programa para realizar informe automático de sucesos para la combinación específica de ID de aplicación VMJJJJ, nombre de trabajo JJJJ y estado. Capítulo 5. Integración con Open Systems 285 Método alternativo para controlar el proceso de VM Enlace VTAM Tivoli OPC en procesador MVS Aplicación VMJJJJ VM Autolog Machine OPCWATCH Recibe EXEC nombre JJJJ Ejecuta OPCSTAT que envía el trabajo de suceso ’S’ a MVS La operación CPU1 010 envía EXEC nombre JJJJ a VM Ejecuta JJJJ Ejecuta OPCSTAT, que envía el trabajo de suceso ’C’ o ’E’ a MVS Operación VM 020 en estado ’W’ El trabajo de VM establece la operación VM 020 en estado ’S’ El trabajo de VM establece la operación VM 020 en estado ’C’ o ’E’ Figura 2. Utilización de notificación automática de sucesos para controlar operaciones de VM Si Tivoli Workload Scheduler for z/OS en ejecución en z/OS falla o si el enlace de comunicación falla, seguirán existiendo un plan de estación de trabajo de impresora y una lista de preparados de Tivoli Workload Scheduler for z/OS de la planificación diaria. Esta información indica qué trabajos se deben ejecutar y el orden en el que se deben ejecutar. Un registro de usuarios de VM de Tivoli Workload Scheduler for z/OS lista los EXEC que se han iniciado y los que se han completado. Con esta información, el proceso puede continuar ya sea automáticamente cuando se restablezca el enlace o bien manualmente. Los trabajos transmitidos a y de VM añaden poca carga adicional a z/OS. Para evitar retardos, se debe reservar un iniciador y una clase de trabajo dedicados para la comunicación de VM. Debido a que Tivoli Workload Scheduler for z/OS no requiere DASD compartido para el método anterior, este método se puede utilizar para dirigir múltiples usuarios de VM en ubicaciones distintas. También puede utilizar este método para dirigir otros sistemas z/OS. Este método es especialmente útil cuando un sistema 286 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Método alternativo para controlar el proceso de VM z/OS remoto ejecuta una pequeña cantidad de copias de seguridad y limpiezas que se inician y controlan desde un sitio central. Capítulo 5. Integración con Open Systems 287 Método alternativo para controlar el proceso de VM 288 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Capítulo 6. Notificación de sucesos a Tivoli Workload Scheduler for z/OS En este capítulo se describe cómo notificar sucesos a Tivoli Workload Scheduler for z/OS. Este capítulo contiene información general de la interfaz de programación y de ayuda asociada. Tivoli Workload Scheduler for z/OS permite realizar el seguimiento de actividades en el entorno de proceso de datos. La información sobre el estado de estas actividades la pueden notificar manualmente los usuarios del diálogo o la puede recopilar Tivoli Workload Scheduler for z/OS automáticamente. Estas actividades se denominan sucesos. Para sistemas z/OS, Tivoli Workload Scheduler for z/OS utiliza salidas SMF y JES para recopilar automáticamente la información de sucesos. Por ejemplo, Tivoli Workload Scheduler for z/OS notifica cuándo se ha iniciado una tarea iniciada o cuándo un trabajo ha finalizado. Pero es posible que haya actividades en la carga de trabajo de producción que no puedan ser detectadas por las salidas JES y SMF y que desee notificar a Tivoli Workload Scheduler for z/OS. Puede hacerlo proporcionando la información de suceso a Tivoli Workload Scheduler for z/OS. Por ejemplo, asuma que una aplicación de Tivoli Workload Scheduler for z/OS depende de un conjunto de datos que actualiza una transacción en línea. Para una aplicación de este tipo, el trabajo por lotes que utiliza el conjunto de datos no se debe iniciar hasta que el conjunto de datos se haya actualizado satisfactoriamente. Se asegura de ello definiendo un recurso especial que requiere el trabajo por lotes pero que no está disponible. A continuación, la transacción en línea puede hacer que el recurso especial esté disponible invocando la subrutina EQQUSIN o emitiendo un mandato SRSTAT en su último paso de proceso. De forma opcional, puede definir una operación en una estación de trabajo automática general establecida para ser completada por la transacción en línea, utilizando EQQUSIN o el mandato OPSTAT. El trabajo por lotes, que depende de esta operación, no se procesa antes de que el conjunto de datos se haya actualizado. Suministro de la información de suceso a Tivoli Workload Scheduler for z/OS Puede notificar información de suceso a Tivoli Workload Scheduler for z/OS, manual y automáticamente, estableciendo procedimientos que utilicen mandatos TSO de Tivoli Workload Scheduler for z/OS y subrutinas de Tivoli Workload Scheduler for z/OS. Puede hacer lo siguiente: v Solicitar una copia de seguridad de un conjunto de datos de Tivoli Workload Scheduler for z/OS utilizando el mandato TSO BACKUP o la subrutina EQQUSIN o EQQUSINB. v Hacer que un recurso especial esté disponible o no disponible utilizando el mandato TSO SRSTAT o la subrutina EQQUSIN o EQQUSINS. v Cambiar el estado de una operación utilizando el mandato TSO OPSTAT o la subrutina EQQUSIN o EQQUSINT. v Actualizar el campo de datos de usuario de una operación en el plan actual utilizando el mandato TSO OPINFO o la subrutina EQQUSIN o EQQUSINO. © Copyright IBM Corp. 1991, 2011 289 Suministro de la información de suceso v Generar un suceso de estado de estación de trabajo para una estación de trabajo del plan actual que especifique un destino definido por el usuario utilizando el mandato TSO WSSTAT o la subrutina EQQUSIN o EQQUSINW. Si planea emitir los mandatos TSO muchas veces al día desde un espacio de direcciones no TSO de larga ejecución, por ejemplo NetView, se recomienda que utilice en su lugar una subrutina. Cuando emite los mandatos desde TSO o como entrada al programa EQQEVPGM, debe establecer cada vez un entorno TSO, y algunos de los recursos permanecen asignados hasta que la tarea finaliza, lo que puede hacer que se agote el almacenamiento si los mandatos se emiten muchas veces. Para obtener más información sobre los mandatos TSO de IBM Tivoli Workload Scheduler for z/OS, consulte la publicación Managing the Workload. En el resto de este capítulo se describe cómo utilizar las subrutinas de IBM Tivoli Workload Scheduler for z/OS. En la publicación Diagnosis Guide and Reference se describe detalladamente cómo se crean los sucesos y cómo IBM Tivoli Workload Scheduler for z/OS los procesa a continuación. Información general sobre subrutinas de Tivoli Workload Scheduler for z/OS Lea esta información antes de utilizar las subrutinas de Tivoli Workload Scheduler for z/OS: v Tivoli Workload Scheduler for z/OS proporciona subrutinas individuales (EQQUSINB, EQQUSINS, EQQUSINO, EQQUSINT y EQQUSINW) y una subrutina general (EQQUSIN), que residen en la biblioteca de distribución AEQQMOD0. Las subrutinas se pueden enlazar al módulo de carga desde el que se invocan o se pueden mover a una biblioteca autorizada e invocar dinámicamente. Independientemente del método que seleccione, estas subrutinas deben ejecutar APF autorizado, en clave PSW 0–7, o en estado de supervisor. Si se invoca una subrutina desde un entorno no autorizado, por ejemplo CICS, se debe invocar desde un usuario SVC. Debido a que estas subrutinas no realizan operaciones de entrada/salida u otras operaciones que impliquen esperas, no afectarán negativamente el rendimiento del entorno desde el que se invoquen. v Las subrutinas no realizan comprobación de seguridad de RACF de los datos que se les pasan. Una razón es que la información de suceso generada por una subrutina se podría utilizar en dos o más espacios de direcciones de Tivoli Workload Scheduler for z/OS donde las reglas de seguridad fueran distintas. El usuario es responsable de la seguridad de la función. Puede proteger estas subrutinas colocándolas en una biblioteca protegida. O bien el programa que invoca la subrutina puede realizar comprobación de seguridad. v La información de suceso que notifica tiene una función principal, pero en muchos casos, puede proporcionar información adicional que puede causar más actualizaciones. Si desea proporciona información adicional mediante una subrutina de Tivoli Workload Scheduler for z/OS, utilice EQQUSIN, que tiene parámetros adicionales que no están disponibles en las subrutinas individuales. EQQUSIN es una subrutina general que puede utilizar en lugar de cualquier rutina individual. Es funcionalmente equivalente a todos los mandatos TSO de Tivoli Workload Scheduler for z/OS. Si ya utiliza subrutinas individuales, puede continuar utilizándolas sin realizar cambios. Sin embargo, sólo se mantienen por razones de compatibilidad; es preferible utilizar EQQUSIN. 290 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Suministro de la información de suceso v Sólo se comprueban los parámetros que pasa a las subrutinas para ver si tienen el formato correcto; es decir, los campos numéricos deben contener solo números en el rango válido, los campos de fecha deben contener fechas válidas, y así sucesivamente. No se comprueba si los parámetros son válidos para un espacio de direcciones específico de Tivoli Workload Scheduler for z/OS. Por ejemplo, el nombre de una estación de trabajo que especifique no se verifica respecto a las estaciones de trabajo reales que existen en un plan actual específico de Tivoli Workload Scheduler for z/OS. Además, se puede generar un único registro de suceso que se utilice en dos o más espacios de direcciones de Tivoli Workload Scheduler for z/OS. Es posible que un parámetro determinado (por ejemplo, el ID de descripción de la aplicación) sea válido para un espacio de direcciones pero no para otro. Si se cumplen los requisitos mínimos de los parámetros y éstos tienen el formato correcto, las subrutinas se ejecutarán satisfactoriamente y se generará un registro de suceso. Cuando controlador procesa el suceso, se comprueba si es válido. Si se encuentran errores, se graba un mensaje de error en el registro de mensajes del controlador (EQQMLOG). v Puede utilizar las subrutinas incluso si Tivoli Workload Scheduler for z/OS (en concreto, la subtarea de grabador de sucesos) no está activo. Los registros de sucesos se siguen generando y colocando en la cola del grabador de sucesos. Cuando se inicia el grabador de sucesos, los registros de sucesos se eliminan de la cola y se graban en el conjunto de datos de suceso. Utilización de la subrutina general de Tivoli Workload Scheduler for z/OS (EQQUSIN) EQQUSIN es una subrutina general que da soporte a todos los tipos de notificación de sucesos. Puede utilizarla en lugar de subrutinas individuales. También proporciona funciones de actualización adicionales. La Apéndice C, “Biblioteca de ejemplos (SEQQSAMP)”, en la página 419 describe ejemplos para ayudarle a utilizar EQQUSIN. Requisitos de invocación EQQUSIN tiene los siguientes requisitos de invocación: Autorización APF autorizado Modalidad de unidad que se puede asignar Modalidad de tarea Amode 31 bits Modalidad ASC Registro primario o de acceso (AR) Estado de interrupción Habilitado para E/S e interrupciones externas Bloqueos No se mantiene ningún bloqueo Parámetros de control Todos los parámetros deben ser direccionables por el emisor de la llamada y estar en el espacio de direcciones primario. Parámetros de EQQUSIN El programa pasa parámetros a EQQUSIN en un almacenamiento intermedio APP. El registro 1 debe apuntar a la dirección del almacenamiento intermedio y el bit de Capítulo 6. Notificación de sucesos 291 Parámetros de EQQUSIN orden alto debe estar activado. El formato del almacenamiento intermedio es el mismo que el que se utiliza para la comunicación con Tivoli Workload Scheduler for z/OS mediante la interfaz de programación de aplicaciones (API). Puede invocar EQQUSIN en sistemas z/OS donde esté instalado Tivoli Workload Scheduler for z/OS. La solicitud se envía mediante la interfaz del subsistema (SSI) a Tivoli Workload Scheduler for z/OS. El código de retorno de la llamada a la SSI se devuelve en el registro 15. EQQUSIN da soporte a múltiples solicitudes en el mismo almacenamiento intermedio. El almacenamiento intermedio puede contener estas secciones: APP Sección fija: identifica el almacenamiento intermedio APPOBJ Sección del objeto: identifica el objeto (tipo de suceso) APPSEL Selección de la sección: contiene un nombre de campo que se utiliza para localizar una o varias instancias del objeto APPVAL Sección del valor de la selección: contiene un valor de campo que se utiliza para localizar una o varias instancias del objeto APPFLD Sección del campo: identifica el campo que se debe actualizar en la instancia seleccionada del objeto APPDAT Sección de datos: contiene un nuevo valor para cada sección APPFLD. La Figura 3 es un ejemplo del diseño de un almacenamiento intermedio. Esta solicitud utiliza 2 campos de selección para localizar un objeto y actualiza 1 campo en el objeto seleccionado. Las flechas muestran las partes del almacenamiento intermedio a las que apunta cada tipo de sección. APP y APPOBJ apuntan a las secciones relacionadas utilizando campos de tres partes, que especifican el desplazamiento, la longitud y el número del tipo de sección. APPSEL utiliza los campos del desplazamiento y de la longitud para apuntar a una sección APPVAL. Todos los desplazamientos son relativos al inicio del almacenamiento intermedio (desplazamiento 0). Figura 3. Ejemplo de almacenamiento intermedio de EQQUSIN Cada sección se describe aquí más detalladamente. APP - sección fija El almacenamiento intermedio que el programa pasa a EQQUSIN debe contener una sección fija y debe ser la primera sección del almacenamiento intermedio. Identifica el almacenamiento intermedio, su tamaño, el tipo de solicitud predeterminado y apunta a secciones de objeto. El almacenamiento intermedio debe contener sólo 1 sección fija, incluso si se pasan varias solicitudes en el mismo almacenamiento intermedio. 292 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste APP - sección fija La sección fija tiene este formato: Desplazamientos Dec 0 Hex (0) Tipo STRUCTURE Lon 80 0 4 6 8 11 12 16 (0) (4) (6) (8) (B) (C) (10) CHARACTER CHARACTER BITSTRING CHARACTER BITSTRING SIGNED CHARACTER 4 2 2 3 1 4 8 24 28 32 (18) (1C) (20) SIGNED SIGNED 4 4 12 32 (20) SIGNED 4 36 (24) SIGNED 4 40 44 (28) (2C) SIGNED SIGNED 4 4 48 56 72 (30) (38) (48) CHARACTER CHARACTER CHARACTER 8 16 8 Nombre APP Descripción CORRELACIÓN DE ALMACENAMIENTO INTERMEDIO APPC APPDESC DESCRIPTOR DE BLOQUE (APP) APPVER NÚMERO DE VERSIÓN (02) * RESERVADO APPTYPE CAPTADOR (DIA) APPFLAGS RESERVADO APPTOTSZ TAMAÑO TOTAL APP_TYPE TIPO DE DATOS DEL DIÁLOGO (CREATE para EQQUSIN) APP_RETCODE *CÓDIGO DE RETORNO APP_RSNCODE *CÓDIGO DE RAZÓN APP_OBJ_TRIPLET SECCIÓN DE OBJETO DE TRES PARTES APP_OBJ_OFF DESPLAZAMIENTO A PRIMERA SECCIÓN DE OBJETO APP_OBJ_LEN LONGITUD DE TODAS LAS SECCIONES DE OBJETO APP_OBJ_NBR NÚMERO DE SECCIONES DE OBJETO d *DESPLAZAMIENTO A ERROR DE VERIFICACIÓN * RESERVADO APPTOKEN *CAMPO DE SEÑAL * RESERVADO En la sección fija: APPDESC Es el descriptor de bloque y tiene el valor APP. APPVER Es el número de versión y tiene el valor 02. * Desplazamiento 6 (X'6'). Establezca este campo reservado en ceros binarios (X'00'). APPTYPE Es el captador y tiene el valor DIA. APPFLAGS Establezca este campo reservado en ceros binarios (X'00'). APPTOTSZ Es el tamaño total del almacenamiento intermedio. APP_TYPE Es el tipo de solicitud que es el valor predeterminado para todas las solicitudes. Se utiliza si no se proporciona un valor para APPOBJ_TYPE en una sección de objeto del almacenamiento intermedio. Si establece este campo en espacios en blanco (X'40'), debe especificar una solicitud en cada sección de objeto del almacenamiento intermedio. Sólo CREATE es válido para EQQUSIN. APP_OBJ_TRIPLET Contiene el desplazamiento de la primera sección APPOBJ, la longitud de todas las secciones y el número de secciones. APP_RETCODE Es el código de retorno establecido por EQQUSIN. En la llamada a EQQUSIN, establezca este campo en ceros binarios (X'00'). Para Capítulo 6. Notificación de sucesos 293 APP - sección fija obtener más información, consulte la sección “Códigos de retorno y códigos de razón generados por EQQUSIN” en la página 306. APP_RSNCODE Es el código de razón establecido por EQQUSIN. En la llamada a EQQUSIN, establezca este campo en ceros binarios (X'00'). Para obtener más información, consulte la sección “Códigos de retorno y códigos de razón generados por EQQUSIN” en la página 306. APP_ERR_OFF Lo establece EQQUSIN cuando APP_RSNCODE indica un error que tiene un desplazamiento asociado a éste. Es el desplazamiento en el almacenamiento intermedio donde se ha encontrado un error de verificación. En la llamada a EQQUSIN, establezca este campo en ceros binarios (X'00'). * Desplazamiento 48 (X'30'). Establezca este campo reservado en ceros binarios (X'00'). APPTOKEN Es un valor que el programa puede establecer para identificar de forma exclusiva un almacenamiento intermedio. Podría ser, por ejemplo, una indicación de fecha y hora. APPTOKEN puede ser útil si invoca EQQUSIN mediante la API y hay más de una solicitud activa del ATP en un momento determinado. * Desplazamiento 72 (X'48'). Establezca este campo reservado en ceros binarios (X'00'). APPOBJ - sección de objeto Esta sección identifica el tipo de suceso que desea notificar a Tivoli Workload Scheduler for z/OS. El almacenamiento intermedio de EQQUSIN debe contener una sección de objeto. Puede contener más de una sección de objeto, pero todas las secciones de objeto deben estar en almacenamiento contiguo; es decir, una debe ir a continuación de la otra. APP_OBJ_TRIPLET en la sección fija apunta a la parte del almacenamiento intermedio que contiene las secciones de objeto. La propia sección APPOBJ apunta a las secciones APPSEL, APPFLD y APPDAT. La sección de objeto tiene este formato: 294 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste APPOBJ - sección de objeto Desplazamientos Dec 0 Hex (0) Tipo STRUCTURE Lon 84 Nombre APPOBJ 0 0 16 24 (0) (0) (10) (18) CHARACTER CHARACTER 24 16 8 12 APPOBJ_ID APPOBJ_NAME APPOBJ_KEY_TYPE APPOBJ_FLD_TRIPLET 24 (18) SIGNED 4 APPOBJ_FLD_OFF 28 (1C) SIGNED 4 APPOBJ_FLD_LEN 32 (20) SIGNED 4 APPOBJ_FLD_NBR 36 (24) 12 APPOBJ_SEL_TRIPLET 36 (24) SIGNED 4 APPOBJ_SEL_OFF d (28) SIGNED d APPOBJ_SEL_LEN 44 (2C) SIGNED 4 APPOBJ_SEL_NBR 48 (30) 12 APPOBJ_DAT_TRIPLET 48 (30) SIGNED 4 APPOBJ_DAT_OFF 52 (34) SIGNED d APPOBJ_DAT_LEN 56 (38) SIGNED d APPOBJ_DAT_NBR 60 (3C) CHARACTER 8 APPOBJ_TYPE 68 (44) SIGNED 4 APPOBJ_RET 72 (48) SIGNED 4 APPOBJ_RSN 76 (4C) CHARACTER 8 APPOBJ_AUTH Descripción SECCIÓN DE OBJETO APPOBJ_PTR = ADDR(APP) + APP_OBJ_OFF IDENTIFICADOR DE OBJETO NOMBRE DE OBJETO TIPO DE CLAVE SECCIÓN DE CAMPO DE TRES PARTES DESPLAZAMIENTO A PRIMERA SECCIÓN DE CAMPO LONGITUD DE TODAS LAS SECCIONES DE CAMPO NÚMERO DE SECCIONES DE CAMPO SECCIÓN DE SELECCIÓN DE TRES PARTES DESPLAZAMIENTO A PRIMERA SECCIÓN DE SELECCIÓN LONGITUD DE TODAS LAS SECCIONES DE SELECCIÓN NÚMERO DE SECCIONES DE SELECCIÓN SECCIÓN DE DATOS DE TRES PARTES DESPLAZAMIENTO A PRIMERA SECCIÓN DE DATOS LONGITUD DE TODAS LAS SECCIONES DE DATOS NÚMERO DE SECCIONES DE DATOS TIPO DE DATOS DEL DIÁLOGO (CREATE para EQQUSIN) CÓDIGO DE RETORNO A NIVEL DE OBJETO CÓDIGO DE RAZÓN A NIVEL DE OBJETO AUTORIZACIÓN DE RACF (READ o UPDATE) En la sección de objeto: APPOBJ_NAME Es el tipo de suceso que desea notificar a Tivoli Workload Scheduler for z/OS. Puede especificar estos nombres de objeto: CP_OPER_EVENT Estado de operación del plan actual. Es equivalente al mandato TSO OPSTAT. CP_OPINFO_EVENT Datos de usuario de la operación del plan actual. Es equivalente al mandato TSO OPINFO. CP_SR_EVENT Recurso especial del plan actual. Es equivalente al mandato TSO SRSTAT. BACKUP_EVENT Solicitud de copia de seguridad. Es equivalente al mandato TSO BACKUP. Capítulo 6. Notificación de sucesos 295 APPOBJ - sección de objeto Estación de trabajo del plan actual. Es equivalente al mandato TSO WSSTAT. CP_WS_EVENT APPOBJ_KEY_TYPE Es el tipo de clave, que debe ser SAME para EQQUSIN. Si establece este campo es espacios en blanco (X'40'), SAME se utiliza como valor predeterminado. APPOBJ_FLD_TRIPLET Contiene el desplazamiento a la primera sección APPFLD, la longitud de cada sección y el número de secciones. Establezca estos campos en ceros binarios (X'00') cuando el objeto sea BACKUP_EVENT. APPOBJ_SEL_TRIPLET Contiene el desplazamiento a la primera sección APPSEL, la longitud de cada sección y el número de secciones. APPOBJ_DAT_TRIPLET Contiene el desplazamiento a la primera sección APPDAT, la longitud de todas las secciones y el número de secciones. Establezca estos campos en ceros binarios (X'00') cuando el objeto sea BACKUP_EVENT. APPOBJ_TYPE Es el tipo de solicitud. Sólo CREATE es válido para EQQUSIN. Si establece este campo en espacios en blanco (X'40'), debe especificar CREATE en el campo APP_TYPE de la sección fija. APPOBJ_RET En la llamada a EQQUSIN, establezca este campo en ceros binarios (X'00'). No se genera ningún código de retorno en la sección de objeto para una solicitud CREATE. APPOBJ_RSN En la llamada a EQQUSIN, establezca este campo en ceros binarios (X'00'). No se genera ningún código de razón en la sección de objeto para una solicitud CREATE. APPOBJ_AUTH Establezca este campo en espacios en blanco (X'40') en la llamada a EQQUSIN. No se actualiza para una solicitud CREATE. APPSEL - sección de la selección Esta sección identifica un campo determinado en el tipo de objeto. El almacenamiento intermedio debe contener una sección de selección. La sección de objeto de APPSEL apunta a ésta y ella misma debe apuntar a una sección APPVAL donde se especifique un valor de selección. Para identificar una instancia determinada de un objeto, es posible que necesite especificar más de una sección APPSEL para cada sección APPOBJ. Las secciones de selección para una sección APPOBJ determinada deben estar en almacenamiento contiguo. La sección de la selección tiene este formato: Desplazamientos Dec Hex 0 (0) 0 (0) 296 Tipo Lon Nombre Descripción STRUCTURE 36 APPSEL CHARACTER 16 APPSEL_NAME DIRECCIÓN DE LA SECCIÓN DE SELECCIÓN O PRIMERA SECCIÓN DE SELECCIÓN PARA ESTE OBJETO: APPSEL_PTR =ADDR(APP) + APPOBJ_SEL_OFF NOMBRE DE CAMPO DE OBJETO IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste APPSEL - sección de la selección Desplazamientos Dec 16 18 28 32 Hex (10) (12) (1C) (20) Tipo CHARACTER CHARACTER SIGNED SIGNED Lon 2 10 4 4 Nombre APPSEL_OPER * APPSEL_VALUE_OFF APPSEL_VALUE_LEN Descripción OPERADOR RESERVADO DESPLAZAMIENTO DEL VALOR LONGITUD DEL VALOR En la sección de la selección: APPSEL_NAME Es un nombre de campo en el objeto. En la “Especificación de los criterios de selección” en la página 298 se describen los nombres que puede especificar para cada tipo de objeto. APPSEL_OPER Es un operador de comparación. Sólo es válido igual a (EQ o =) para EQQUSIN. * Desplazamiento 18 (X'12'). Establezca este campo reservado en ceros binarios (X'00'). APPSEL_VALUE_OFF Es el desplazamiento a la sección APPVAL. APPSEL_VALUE_LEN Es la longitud de la sección APPVAL. APPVAL - sección del valor de la selección Esta sección contiene un valor de selección para el campo identificado en APPSEL. APPSEL apunta a APPVAL, que se debe incluir. Es necesaria una sección APPVAL para cada sección APPSEL. La sección del valor de la selección tiene este formato: Desplazamientos Dec Hex 0 (0) 0 (0) Tipo Lon Nombre Descripción STRUCTURE * APPVAL (Ver nota) * APPVAL_DAT DIRECCIÓN DE SECCIÓN DE DATOS DE PRIMERA SECCIÓN DE DATOS PARA ESTE OBJETO: APPVAL_PTR=ADDR(APP) + APPSEL_VALUE_OFF DATOS Nota: El tipo de campo depende del nombre de campo de objeto que se especifica en APPSEL_NAME. APPFLD - sección del campo Cada sección de campo identifica un campo en el objeto seleccionado que desea actualizar; por ejemplo, el estado de una operación en el plan actual. APPFLD no se utiliza cuando el nombre de objeto es BACKUP_EVENT, pero es necesario para todos los demás nombres de objetos. APPOBJ_FLD_TRIPLET en la sección de objeto apunta a las secciones de campos. Puede especificar más de una sección APPFLD para cada APPOBJ, pero todas las secciones de campos para una sección APPOBJ determinada deben estar en almacenamiento contiguo. La sección del campo tiene este formato: Capítulo 6. Notificación de sucesos 297 APPFLD - sección del campo Desplazamientos Dec Hex 0 (0) 0 16 20 (0) (10) (14) Tipo Lon Nombre Descripción STRUCTURE 24 APPFLD CHARACTER SIGNED CHARACTER 16 4 4 APPFLD_NAME APPFLD_LEN APPFLD_TYPE DIRECCIÓN DE SECCIÓN DE CAMPO DE SECCIÓN DE PRIMER CAMPO PARA ESTE OBJETO: APPFLD_PTR= ADDR(APP) + APPOBJ_FLD_OFF NOMBRE DEL CAMPO LONGITUD DEL CAMPO *TIPO DE DAOTS DEL CAMPO En la sección del campo: APPFLD_NAME Es el nombre del campo. En la sección “Especificación de los campos de objetos que se actualizarán” en la página 303 se describen los campos que puede especificar para cada tipo de objeto. APPFLD_LEN Es la longitud del campo y se utiliza para identificar el valor en APPDAT para este campo. APPFLD_TYPE Es el tipo de datos. EQQUSIN ignora cualquier valor en este campo. APPDAT - sección de datos La sección de datos es siempre la última sección del almacenamiento intermedio. Contiene los nuevos valores de los campos identificados en las secciones APPFLD. Los valores deben estar en el mismo orden que sus secciones APPFLD correspondientes. Sólo es necesaria una sección APPDAT para cada sección APPOBJ. La sección de datos tiene este formato: Desplazamientos Dec Hex 0 (0) 0 (0) Tipo Lon Nombre Descripción STRUCTURE * APPDAT (Ver nota) * APPDAT_DAT DIRECCIÓN DE SECCIÓN DE DATOS DE PRIMERA SECCIÓN DE DATOS PARA ESTE OBJETO: APPDAT_PTR=ADDR(APP) + APPOBJ_DAT_OFF DATOS Nota: El tipo de datos depende del nombre del campo de objeto que especifique en APPFLD_NAME. Especificación de los criterios de selección Aquí se describen los valores de selección de los campos que puede proporcionar en APPSEL y APPVAL para cada tipo de objeto. Se utilizan para identificar la instancia del objeto para la que desea crear un suceso. 298 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Especificación de los criterios de selección Selección de una operación para cambiar el estado (CP_OPER_EVENT) Puede especificar estos campos para identificar una operación de plan actual para la que desea cambiar el estado: Tabla 29. Campos de selección de CP_OPER_EVENT Campo Tipo Tamaño SUBSYSTEM_NAME CHAR 4 Nombre del subsistema WS_NAME CHAR 4 Nombre de la estación de trabajo JOBNAME CHAR 8 Nombre del trabajo APPL_ID CHAR 16 ID de aplicación BIN 15 Número de operación APPL_IA_DATE CHAR 6 Fecha de llegada de entrada (AAMMDD) APPL_IA_TIME CHAR 4 Hora de llegada de entrada (HHMM) FORM_NUMBER CHAR 8 Número de formulario CLASS CHAR 1 Clase SYSOUT OPER_TOKEN CHAR 8 Señal de operación OPER_NUM Descripción SUBSYSTEM_NAME Nombre del subsistema del comprobador de seguimiento al que se debe notificar el suceso. Si no se especifica SUBSYSTEM_NAME o tiene el valor MSTR, se realiza la difusión del suceso utilizando la interfaz del subsistema (SSI) a todos los subsistemas Tivoli Workload Scheduler for z/OS en la imagen z/OS donde se invoca EQQUSIN. WS_NAME Nombre de la estación de trabajo. JOBNAME Nombre del trabajo para el que se notifica un suceso. APPL_ID Nombre de la aplicación actual. OPER_NUM Número, en formato binario, de la operación actual. El número puede tener un valor decimal de 1 a 255. APPL_IA_DATE Fecha de llegada de entrada de la aparición actual con el formato AAMMDD. APPL_IA_TIME Hora de llegada de entrada de la aparición actual con el formato HHMM. FORM_NUMBER Contiene el número de formulario de la impresora para operaciones en las estaciones de trabajo de impresora. CLASS Contiene la clase SYSOUT para operaciones en las estaciones de trabajo de impresora. OPER_TOKEN Valor hexadecimal que identifica de forma exclusiva una operación. Si ha almacenado la señal establecida en el parámetro OPCTOKEN de la salida de iniciación de la operación (EQQUX009), puede proporcionar esta señal a EQQUSIN para identificar de forma Capítulo 6. Notificación de sucesos 299 Especificación de los criterios de selección exclusiva la operación. OPER_TOKEN es válido sólo para operaciones en estaciones de trabajo que tienen un destino definido por el usuario. Nota: Como OPCTOKEN se define como una palabra completa, OPER_TOKEN se debe rellenar de la forma siguiente: FIRST WORD SECOND WORD = X’00000000’ = OPCTOKEN FROM EXIT EQQUX009 Notas: 1. Debe especificar como mínimo OPER_TOKEN o WS_NAME con JOBNAME o APPL_ID. 2. Si no proporciona suficiente información para identificar la operación de forma exclusiva, Tivoli Workload Scheduler for z/OS debe determinar la operación más aplicable para actualizar. Al seleccionar la operación, Tivoli Workload Scheduler for z/OS considera sólo las operaciones en estado R, A, *, S, I o E. Tivoli Workload Scheduler for z/OS selecciona la operación que se debe actualizar investigando estas características en el orden indicado: a. La operación tiene una prioridad 9. b. La última hora de inicio más temprana. c. Prioridad 8-1. d. La hora de comienzo planificado especificada para la operación o el comienzo planificado de la aparición si la operación no tiene un comienzo planificado específicamente definido. Por lo tanto, a partir de las operaciones que coinciden con los criterios de selección, se actualiza la operación con prioridad 9. Si más de una operación tiene prioridad 9, se actualiza la operación con la última hora de inicio más temprana. Si el último inicio es igual, se actualiza la operación con la prioridad más alta. Si la prioridad es igual, se actualiza la operación con la hora de llegada de entrada más temprana. Si la llegada de entrada es igual, se realiza la actualización en función del "primero en llegar, primero es salir". Selección de un recurso especial (CP_SR_EVENT) Puede especificar estos campos para identificar un recurso especial del plan actual: Tabla 30. Campos de selección de CP_SR_EVENT Campo 300 Tipo Tamaño Descripción SUBSYSTEM_NAME CHAR 4 Nombre del subsistema SR_NAME CHAR 44 Nombre del recurso especial SUBSYSTEM_NAME Nombre del subsistema del comprobador de seguimiento al que se debe notificar el suceso. Si no se especifica SUBSYSTEM_NAME o tiene el valor MSTR, se realiza la difusión del suceso utilizando la interfaz del subsistema (SSI) a todos los subsistemas Tivoli Workload Scheduler for z/OS en la imagen z/OS donde se invoca EQQUSIN. SR_NAME Nombre del recurso especial. IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Especificación de los criterios de selección Selección de una operación para proporcionar datos de usuario (CP_OPINFO_EVENT) Puede especificar estos campos para identificar una operación del plan actual para la que desea actualizar el campo USERDATA: Tabla 31. Campos de selección de CP_OPINFO_EVENT Campo Tipo Tamaño SUBSYSTEM_NAME CHAR 4 Nombre del subsistema WS_NAME CHAR 4 Nombre de la estación de trabajo JOBNAME CHAR 8 Nombre del trabajo APPL_ID CHAR 16 ID de aplicación BIN 15 Número de operación APPL_IA_DATE CHAR 6 Fecha de llegada de entrada (AAMMDD) APPL_IA_TIME CHAR 4 Hora de llegada de entrada (HHMM) FORM_NUMBER CHAR 8 Número de formulario CLASS CHAR 1 Clase SYSOUT STATUS CHAR 1 Estado de la operación OPER_NUM Descripción SUBSYSTEM_NAME Nombre del subsistema del comprobador de seguimiento al que se debe notificar el suceso. Si no se especifica SUBSYSTEM_NAME o tiene el valor MSTR, se realiza la difusión del suceso utilizando la interfaz del subsistema (SSI) a todos los subsistemas Tivoli Workload Scheduler for z/OS en la imagen z/OS donde se invoca EQQUSIN. WS_NAME Nombre de la estación de trabajo. JOBNAME Nombre del trabajo para el que se notifica un suceso. APPL_ID Nombre de la aplicación actual. OPER_NUM Número, en formato binario, de la operación actual. El número puede tener un valor decimal de 1 a 255. APPL_IA_DATE Fecha de llegada de entrada de la aparición actual con el formato AAMMDD. APPL_IA_TIME Hora de llegada de entrada de la aparición actual con el formato HHMM. FORM_NUMBER Contiene el número de formulario de la impresora para operaciones en las estaciones de trabajo de impresora. CLASS Contiene la clase SYSOUT para operaciones en las estaciones de trabajo de impresora. STATUS Estado actual de la operación. Nota: Si la palabra clave OPINFOSCOPE de la sentencia JTOPTS es IP, que es el valor predeterminado, debe especificar WS_NAME. Si OPINFOSCOPE es Capítulo 6. Notificación de sucesos 301 Especificación de los criterios de selección ALL, debe especificar APPL_ID o JOBNAME. La palabra clave OPINFOSCOPE se describe en la página 96. Selección de un conjunto de datos de Tivoli Workload Scheduler for z/OS (BACKUP_EVENT) Puede especificar estos campos para identificar un conjunto de datos de IBM Tivoli Workload Scheduler for z/OS: Tabla 32. Campos de selección de BACKUP_EVENT Campo Tipo Tamaño Descripción SUBSYSTEM_NAME CHAR 4 Nombre del subsistema FILENAME CHAR 2 Nombre del conjunto de datos (CP o JS) SUBSYSTEM_NAME Es el nombre del subsistema del comprobador de seguimiento al que se debe notificar el suceso. Si no se especifica SUBSYSTEM_NAME o tiene el valor MSTR, se realiza la difusión del suceso utilizando la interfaz del subsistema (SSI) a todos los subsistemas Tivoli Workload Scheduler for z/OS en la imagen z/OS donde se invoca EQQUSIN. FILENAME Es CP (plan actual) o JS (repositorio JCL). Nota: Los valores de APPSEL son suficientes para crear un suceso BACKUP. Las secciones APPFLD y APPDAT no se utilizan para este tipo de suceso. Selección de una estación de trabajo (CP_WS_EVENT) Puede especificar estos campos para identificar una estación de trabajo del plan actual: Tabla 33. Campos de selección de CP_WS_EVENT Campo Tipo Tamaño Descripción SUBSYSTEM_NAME CHAR 4 Nombre del subsistema DESTINATION CHAR 8 Nombre de destino WS_NAME CHAR 4 Nombre de la estación de trabajo SUBSYSTEM_NAME Es el nombre del subsistema del comprobador de seguimiento al que se debe notificar el suceso. Si no se especifica SUBSYSTEM_NAME o tiene el valor MSTR, se realiza la difusión del suceso utilizando la interfaz del subsistema (SSI) a todos los subsistemas Tivoli Workload Scheduler for z/OS en la imagen z/OS donde se invoca EQQUSIN. DESTINO Es el nombre especificado en el campo de destino de la estación de trabajo. Debe ser un destino definido por el usuario. WS_NAME Es el nombre de la estación de trabajo. Nota: Debe seleccionar como mínimo WS_NAME para un suceso de estación de trabajo. 302 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Especificación de los campos de objetos que se actualizarán Especificación de los campos de objetos que se actualizarán Aquí se describen los campos que puede actualizar en cada tipo de objeto y los nuevos valores que puede proporcionar: Actualización del estado de la operación (CP_OPER_EVENT) Puede actualizar estos campos en una operación del plan actual: Tabla 34. Campos de operación que puede actualizar mediante CP_OPER_EVENT Campo Tipo Tamaño STATUS CHAR 1 Nuevo estado (C, E, I, Q, S, T o X) ERROR_CODE CHAR 4 Código de error (para nuevo estado E) ACT_DUR CHAR 4 Duración real HHMM (para nuevo estado C o E) ACT_END_TIME CHAR 4 Hora de finalización real HHMM (para nuevo estado C o E) EV_CREATION_DATE CHAR 4 Fecha de creación de suceso (01AADDDF) EV_CREATION_TIME BIN 31 Hora de creación de suceso (100 * segundos) CHAR 5 Número de trabajo JOB_NUMBER STATUS Descripción Es el nuevo estado de la operación. Estos valores son válidos: C Establece el estado de la operación en completado. E Establece el estado de la operación en finalizada con error. I Establece el estado de la operación en interrumpida. Q Establece el estado ampliado de una operación iniciada en Q para indicar que la operación está en cola en espera de ejecución. S Establece el estado de la operación en iniciado. T Establece el estado ampliado de una operación iniciada en S para indicar que la operación está en ejecución. X Restablece el estado actual de esta operación. ERROR_CODE Es el código de error de una operación notificada como finalizada con error. ACT_DUR Es la duración, en horas y minutos, de una operación notificada como completada o finalizada en error. ACT_END_TIME Es la hora a la que la operación se ha notificado como completada o finalizada con error. EV_CREATION_DATE Contiene la fecha del suceso que se está notificando. Si el campo contiene sólo ceros binarios (X'00'), Tivoli Workload Scheduler for z/OS utiliza la fecha actual. Capítulo 6. Notificación de sucesos 303 Especificación de los campos de objetos que se actualizarán EV_CREATION_TIME Contiene la hora del suceso que se está notificando. Si el campo contiene sólo ceros binarios (X'00'), Tivoli Workload Scheduler for z/OS utiliza la hora actual. JOB_NUMBER Es un número que puede proporcionar para el trabajo. JOB_NUMBER es válido sólo para operaciones en estaciones de trabajo automáticas generales y estaciones de trabajo que tienen un destino definido por el usuario. No especifique JOB_NUMBER para operaciones que se envíen mediante un comprobador de seguimiento. Nota: Debe especificar como mínimo STATUS. Los otros nombres de campos son opcionales. Actualización de un recurso especial (CP_SR_EVENT) Puede actualizar estos campos a un recurso especial del plan actual: Tabla 35. Campos de recurso especial que puede actualizar mediante CP_SR_EVENT Campo Tipo Tamaño Descripción AVAILABLE CHAR 1 Disponibilidad (Y|N|K|R) QUANTITY BIN 31 Número disponible (de 1 a 999 999) CHAR 8 Opción de cantidad (KEEP|RESET) BIN 31 Número a desviar (de -999 999 a 999 999) DEVIATION_OPTION CHAR 8 Opción de desviación (KEEP|RESET) CREATE CHAR 1 Crea el recurso si no está definido (Y|N) QUANTITY_OPTION DEVIATION DISPONIBLE Es el estado de disponibilidad del recurso especial. Y indica que el estado de disponibilidad del recurso se debe establecer en YES; N indica que el estado debe ser NO. R (RESET) establece el estado en el estado de disponibilidad planificado en el plan actual. K (KEEP), el valor predeterminado, no cambia el estado. CANTIDAD Es un valor numérico (1–999 999) que actualiza el campo de cantidad en el recurso especial, que sustituye los valores de intervalo y predeterminados. Los campos QUANTITY y QUANTITY_OPTION se excluyen mutuamente. Si especifica ambos campos, el suceso se ignora. QUANTITY_OPTION Es KEEP o RESET. Especifique RESET para establecer la cantidad en el valor planificado en el plan actual o KEEP, el valor predeterminado, para dejar la cantidad tal y como está. Si especifica QUANTITY y QUANTITY_OPTION, el suceso se ignora. DEVIATION 304 Es un valor numérico, de −999 999 a 999 999, que permite realizar un cambio temporal en la cantidad. La desviación es la cantidad que se debe sumar a (número positivo) o restar de (número negativo) la cantidad actual. Por ejemplo, si especifica -2 y la cantidad actual es 10, la cantidad total que las operaciones pueden asignar se reduce a 8. Los campos DEVIATION y DEVIATION_OPTION se excluyen mutuamente. Si especifica ambos campos, el suceso se ignora. IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Especificación de los campos de objetos que se actualizarán DEVIATION_OPTION Es KEEP o RESET. Especifique RESET para establecer la desviación en cero. KEEP, el valor predeterminado, no cambia la desviación. Si especifica DEVIATION y DEVIATION_OPTION, el suceso se ignora. CREATE Especifica si Tivoli Workload Scheduler for z/OS debe crear un recurso en el plan actual si el recurso no existe. NO indica que el recurso se debe añadir a las definiciones de recursos del subsistema Tivoli Workload Scheduler for z/OS receptor. Si el recurso ya está definido en el subsistema receptor, NO no tiene ningún efecto. Puede especificar NO si el recurso se está utilizando sólo como un medio para generar un suceso para ETT: el suceso se genera incluso si el recuso no existe. Si se especifica YES y la palabra clave DYNAMICADD de la sentencia de inicialización RESOPTS está establecida en YES o EVENT, se crea una definición de recurso en el subsistema Tivoli Workload Scheduler for z/OS receptor si el recurso no está aún definido. Nota: Cuando establece la cantidad o disponibilidad de un recurso mediante EQQUSIN (u otras interfaces como por ejemplo el mandato TSO SRSTAT o el diálogo MCP), el valor especificado se mantiene a través de los límites de intervalo, aunque el siguiente intervalo pueda especificar un valor distinto. Especifique RESET para restaurar el valor planificado. Actualización de un campo de datos de usuario (CP_OPINFO_EVENT) Puede actualizar este campo en una operación del plan actual con información de datos de usuario: Tabla 36. Campos de operación que puede actualizar mediante CP_OPINFO_EVENT Campo USERDATA USERDATA Tipo Tamaño CHAR 16 Descripción Datos de usuario (texto de formulario libre) Es la información de datos de usuario de 16 caracteres que se actualizará para la operación especificada. Actualización de una estación de trabajo (CP_WS_EVENT) Puede actualizar estos campos en una estación de trabajo del plan actual: Tabla 37. Campos de estación de trabajo que puede actualizar mediante CP_WS_EVENT Campo Tipo Tamaño Descripción WS_STATUS CHAR 1 Estado de la estación de trabajo STARTED_FAIL_OPT CHAR 1 Opción de anomalía para operaciones iniciadas (R, L o E) REROUTE_OPT CHAR 1 Opción de redirección (Y o N) ALT_WS CHAR 4 Nombre de la estación de trabajo alternativa Capítulo 6. Notificación de sucesos 305 Especificación de los campos de objetos que se actualizarán WS_STATUS Es el estado que desea notificar para la estación de trabajo: A Activo O Fuera de línea F Fallido. STARTED_FAIL_OPT Cuando el estado de la estación de trabajo se establece en fuera de línea o anómalo, puede especificar lo que Tivoli Workload Scheduler for z/OS debe hacer con las operaciones que están actualmente en estado iniciado en este destino (estación de trabajo): R Reinicia automáticamente las operaciones en la estación de trabajo alternativa L Deja las operaciones en estado iniciado E Establece todas las operaciones iniciadas en finalizada con error. REROUTE_OPT Cuando el estado de la estación de trabajo se establece en fuera de línea o anómalo, puede especificar Y para que las operaciones se redireccionen a la estación de trabajo alternativa, o N para que no se realice ningún redireccionamiento si desea dejar las operaciones en la estación de trabajo inactiva. ALT_WS Cuando el estado de la estación de trabajo se establece en fuera de línea o anómalo, puede especificar una estación de trabajo alternativa donde se deben iniciar las operaciones redireccionadas. Notas: 1. Debe especificar como mínimo WS_STATUS. 2. Si el valor proporcionado para WS_STATUS es igual al estado actual, el suceso se ignora. Códigos de retorno y códigos de razón generados por EQQUSIN El programa puede probar los resultados de la llamada a EQQUSIN inspeccionando el código de retorno y el código de razón en la sección APP del almacenamiento intermedio. El campo APP_RETCODE puede contener uno de estos códigos: 0 Ejecución satisfactoria. 12 Ejecución no satisfactoria; el almacenamiento intermedio no es válido. No se ha creado ningún suceso. El campo APP_RSNCODE puede contener uno de estos códigos: 0 Ejecución satisfactoria. 4 Almacenamiento intermedio más corto que APP. 8 El captador en el campo APPDESC no es válido. Debe ser APP. 12 El número de versión del campo APPVER no es válido. Debe ser 02. 16 El tipo en el campo APPTYPE no es válido. Debe ser DIA. 20 APPTOTSZ no válido. 24 El tipo de datos no es válido. Especifique sólo CREATE para EQQUSIN. 28 La sección del objeto no está dentro del almacenamiento intermedio. 306 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Códigos de retorno y códigos de razón generados por EQQUSIN 32 36 40 44 48 52 56 60 64 68 La sección del objeto se superpone con APP. La sección de la selección no está dentro del almacenamiento intermedio. La sección de la selección se superpone con la sección APP o del objeto. La sección del campo no está dentro del almacenamiento intermedio. La sección del campo se superpone con la sección APP o del objeto. Clave necesaria no completada. Nombre de objeto no válido en sección OBJ. Nombre de campo no válido en la sección FLD. Nombre de campo no válido en la sección SEL. Valor de APPTOKEN no válido (duplicado). Si se produce un error cuando IBM Tivoli Workload Scheduler for z/OS procesa el suceso, compruebe el registro de mensajes (EQQMLOG) del controlador para obtener información sobre el error. Utilización de subrutinas individuales de Tivoli Workload Scheduler for z/OS En la entrada de estas subrutinas, el registro 1 debe apuntar a una lista de parámetros. Esta lista de parámetros consta de una secuencia de direcciones de 4 bytes a los parámetros. En las secciones siguientes se describen detalladamente los parámetros para cada subrutina. Nota: El APAR PQ74854 ha modificado la modalidad de direccionamiento de las subrutinas siguientes de Amode(24) a Amode(ANY), lo que proporciona la posibilidad de utilizar la modalidad de direccionamiento de 31 bits antes de invocar subrutinas z/OS. Utilización de EQQUSINB Utilice EQQUSINB para solicitar a Tivoli Workload Scheduler for z/OS que copie un conjunto de datos de recursos. Requisitos de invocación EQQUSINB tiene los siguientes requisitos de invocación: Autorización APF autorizado, o estado de supervisor o clave PSW 0–7. Modalidad de unidad que se puede asignar Modalidad de tarea. Amode 24 bits o cualquiera (ANY) si se ha aplicado el APAR PQ74854. Modalidad ASC Registro primario o de acceso (AR). Estado de interrupción Habilitado para E/S e interrupciones externas Bloqueos No se mantiene ningún bloqueo. Parámetros de control Todos los parámetros deben ser direccionables por el emisor de la llamada y estar en el espacio de direcciones primario. Parámetro EQQUSINB El programa de llamada debe pasar todos estos parámetros a la subrutina. Inicialice RETCODE en cero en la llamada; lo establece EQQUSINB en el retorno. Capítulo 6. Notificación de sucesos 307 Utilización de EQQUSINB Parámetros EQQUSINB DATASET SUBSYS RETCODE DS DS DS CL2 CL4 F (Nombre de conjunto de datos del recurso) (Nombre del subsistema) (Código de retorno de EQQUSINB) conjunto de datos Define el conjunto de datos del recurso del que se realizará copia de seguridad. Los valores válidos son: CP Conjunto de datos del plan actual JS Conjunto de datos del depósito del JCL. SUBSYS Es el nombre del subsistema del comprobador de seguimiento al que se debe notificar este suceso. Si SUBSYS está en blanco, se realiza la difusión del suceso a todos los subsistemas Tivoli Workload Scheduler for z/OS definidos en el sistema z/OS donde se invoca EQQUSINB. RETCODE Lo establece EQQUSINB y sólo puede tener uno de estos valores: 0 Retorno normal. El suceso se ha notificado a Tivoli Workload Scheduler for z/OS. 8 Retorno de error. Existe un error en la información que se ha pasado a EQQUSINB. No se ha notificado ningún suceso a Tivoli Workload Scheduler for z/OS. Utilización de EQQUSINO Puede utilizar EQQUSINO para solicitar a Tivoli Workload Scheduler for z/OS que proporcione información en los datos de usuario de una operación del plan actual. El estado actual de la operación debe ser R, A, *, S, I, E, C o W. Pero puede actualizar una operación en estado C o W sólo si la palabra clave OPINFOSCOPE de JTOPTS tiene el valor ALL. OPINFOSCOPE se describe en la página 96. | | | | | Requisitos de invocación EQQUSINO tiene los siguientes requisitos de invocación: Autorización APF autorizado, o estado de supervisor o clave PSW 0–7. Modalidad de unidad que se puede asignar Modalidad de tarea. Amode 24 bits o cualquiera (ANY) si se ha aplicado el APAR PQ74854. Modalidad ASC Registro primario o de acceso (AR). Estado de interrupción Habilitado para E/S e interrupciones externas Bloqueos No se mantiene ningún bloqueo. Parámetros de control Todos los parámetros deben ser direccionables por el emisor de la llamada y estar en el espacio de direcciones primario. Parámetros de EQQUSINO El programa de llamada debe pasar todos estos parámetros a la subrutina. Si la palabra clave OPINFOSCOPE es IP, que es el valor predeterminado, WSNAME es un parámetro necesario. Si OPINFOSCOPE es ALL, debe especificar valores válidos 308 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Utilización de EQQUSINO para el parámetro ADID o el parámetro JOBNAME. Los demás parámetros pueden estar en blanco (cero para OPNUM). Inicialice RC en cero en la llamada; lo establece EQQUSINO en el retorno. Parámetros de EQQUSINO WSNAME JOBNAME ADID OPNUM OCIA FORM CLASS SUBSYS USERDATA RC DS DS DS DS DS DS DS DS DS DS CL4 CL8 CL16 H CL10 CL8 CL1 CL4 CL16 F (Nombre de la estación de trabajo) (Nombre del trabajo) (Nombre de la aplicación actual) (Número de operación o cero) (Llegada de entrada de Occ, AAMMDDHHMM, o en blanco) (Número de formulario de SYSOUT o en blanco) (Trabajo o clase SYSOUT o en blanco) (Nombre del comprobador de seguimiento o en blanco) (Datos de usuario para proporcionar a la operación) (Código de retorno de EQQUSINO) WSNAME Es el nombre de la estación de trabajo definida para la operación. JOBNAME Es el nombre del trabajo definido para la operación que desea actualizar. ADID Es el ID de aplicación que contiene la operación. OPNUM Es el número, en formato hexadecimal, de la operación actual. Puede especificar X'0000' o un número en el rango de X'0001' a X'00FF' (decimal 1 a 255). OCIA Es la fecha y hora de llegada de entrada para la nueva aparición. FORM Contiene el número de formulario de la impresora para operaciones en las estaciones de trabajo de impresora. CLASS Contiene la clase de trabajo o clase SYSOUT definida para la operación. SUBSYS Es el nombre del subsistema del comprobador de seguimiento al que se debe notificar este suceso. Si SUBSYS está en blanco, se realiza la difusión del suceso a todos los subsistemas Tivoli Workload Scheduler for z/OS definidos en el sistema z/OS donde se invoca EQQUSINO. USERDATA Es la información de datos de usuario de 16 caracteres que se actualizará para la operación especificada. RC Lo establece EQQUSINO y puede tener uno de estos valores: 0 Retorno normal. El suceso se ha notificado a Tivoli Workload Scheduler for z/OS. 8 Retorno de error. Existe un error en la información que se ha pasado a EQQUSINO; no se ha notificado ningún suceso a Tivoli Workload Scheduler for z/OS. Nota: Si no proporciona suficiente información para identificar la operación de forma exclusiva, Tivoli Workload Scheduler for z/OS debe determinar la operación más aplicable para actualizar. Tivoli Workload Scheduler for z/OS considera en primer lugar sólo las operaciones en estado R, A, *, S, I o E al seleccionar la operación. Tivoli Workload Scheduler for z/OS selecciona la operación que se debe actualizar investigando estas características en el orden indicado: Capítulo 6. Notificación de sucesos 309 Utilización de EQQUSINO La operación tiene una prioridad 9. La última hora de inicio más temprana. Prioridad 8-1. La hora de comienzo planificado especificada para la operación o el comienzo planificado de la aparición si la operación no tiene un comienzo planificado específicamente definido. 5. Más tiempo en estado preparado. 1. 2. 3. 4. Por lo tanto, si define sólo el parámetro WSNAME y Tivoli Workload Scheduler for z/OS determina que existe más de una operación en el plan actual para esa estación de trabajo, la operación con prioridad 9 se actualiza. Si más de una operación tiene prioridad 9, se actualiza la operación con la última hora de inicio más temprana. Si el último inicio es igual, se actualiza la operación con la prioridad más alta. Si la prioridad es igual, se actualiza la operación con la hora de llegada de entrada más temprana. Si no se ha encontrado ninguna coincidencia para las operaciones con estado R, A, *, S, I o E, Tivoli Workload Scheduler for z/OS utiliza el valor de la palabra clave OPINFOSCOPE de JTOPTS para determinar si también se tienen en cuenta las operaciones en estado C y W. OPINFOSCOPE puede tener el valor IP (en curso) o ALL. Si el valor es ALL, se tendrán en cuenta las operaciones con estado C y W. Se seleccionará la operación con la última hora de inicio más temprana. Utilización de EQQUSINS Puede utilizar EQQUSINS para solicitar a Tivoli Workload Scheduler for z/OS que cambie la disponibilidad de un recurso especial. Requisitos de invocación EQQUSINS tiene los siguientes requisitos de invocación: Autorización APF autorizado, o estado de supervisor o clave PSW 0–7. Modalidad de unidad que se puede asignar Modalidad de tarea. Amode 24 bits o cualquiera (ANY) si se ha aplicado el APAR PQ74854. Modalidad ASC Registro primario o de acceso (AR). Estado de interrupción Habilitado para E/S e interrupciones externas Bloqueos No se mantiene ningún bloqueo. Parámetros de control Todos los parámetros deben ser direccionables por el emisor de la llamada y estar en el espacio de direcciones primario. Parámetros de EQQUSINS El programa de llamada debe pasar todos estos parámetros a la subrutina. Inicialice RC en cero en la llamada; lo establece EQQUSINS en el retorno. 310 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Utilización de EQQUSINS Parámetros de EQQUSINS SRNAME SUBSYS AINDIC RC DS DS DS DS CL44 CL4 CL1 F (Nombre del recurso especial) (Nombre del subsistema) (Indicador de disponibilidad, Y o N) (Código de retorno de EQQUSINS) SRNAME Define el nombre del recurso especial que se debe actualizar. SUBSYS Es el nombre del subsistema del comprobador de seguimiento al que se debe notificar este suceso. Si SUBSYS está en blanco, se realiza la difusión del suceso a todos los subsistemas Tivoli Workload Scheduler for z/OS definidos en el sistema z/OS donde se invoca EQQUSINS. AINDIC Especifica si el recurso especial se debe establecer en disponible (Y) o no disponible (N). RC Lo establece EQQUSINS y sólo puede tener uno de estos valores: 0 Retorno normal. El suceso se ha notificado a Tivoli Workload Scheduler for z/OS. 8 Retorno de error. Existe un error en la información que se ha pasado a EQQUSINS. No se ha notificado ningún suceso a Tivoli Workload Scheduler for z/OS. Utilización de EQQUSINT Puede utilizar EQQUSINT para solicitar a Tivoli Workload Scheduler for z/OS que cambie el estado de una operación en una estación de trabajo. La estación de trabajo puede ser de cualquier tipo, a excepción de una estación de trabajo con el atributo no de informe. Requisitos de invocación EQQUSINT tiene los siguientes requisitos de invocación: Autorización APF autorizado, o estado de supervisor o clave PSW 0–7. Modalidad de unidad que se puede asignar Modalidad de tarea. Amode 24 bits o cualquiera (ANY) si se ha aplicado el APAR PQ74854. Modalidad ASC Registro primario o de acceso (AR). Estado de interrupción Habilitado para E/S e interrupciones externas Bloqueos No se mantiene ningún bloqueo. Parámetros de control Todos los parámetros deben ser direccionables por el emisor de la llamada y estar en el espacio de direcciones primario. Parámetros de EQQUSINT El programa de llamada debe pasar todos estos parámetros a la subrutina. Inicialice RETCODE en cero en la llamada; lo establece EQQUSINT en el retorno. Capítulo 6. Notificación de sucesos 311 Utilización de EQQUSINT Parámetros de EQQUSINT TYPE WSNAME JOBNAME ADID OPNUM OCIA OPDUR OPERR FORM SCLASS SUBSYS EVTIME EVDATE RETCODE TYPE 312 DS DS DS DS DS DS DS DS DS DS DS DS DS DS CL1 CL4 CL8 CL16 H CL10 CL4 CL4 CL8 CL1 CL4 F CL4 F (Tipo de suceso) (Nombre de la estación de trabajo) (Nombre del trabajo) (Nombre de la aplicación actual) (Número de operación) (Llegada de entrada de aparición actual, AAMMDDHHMM) (Duración de la operación, HHMM) (Código de error) (Número de formulario SYSOUT) (Clase SYSOUT) (Nombre del subsistema) (Hora del suceso, 100*seg) (Fecha del suceso, 0nYYDDDF) (Código de retorno de EQQUSINT) Define la razón por la que se invoca EQQUSINT. Estos valores son válidos: C Establece el estado de la operación en completado. E Establece el estado de la operación en finalizada con error. I Establece el estado de la operación en interrumpida. Q Establece el estado ampliado de una operación iniciada en Q para indicar que la operación está en cola en espera de ejecución. S Establece el estado de la operación en iniciado. T Establece el estado ampliado de una operación iniciada en S para indicar que la operación está en ejecución. X Restablece el estado actual de esta operación. WSNAME Es el nombre de la estación de trabajo. JOBNAME Es el nombre del trabajo para el que se está notificando un suceso. ADID Es el nombre de la aplicación actual. OPNUM Es el número, en formato hexadecimal, de la operación actual. Puede especificar 0000 o un número en el rango de 0001 a 00FF (decimal 1 a 255). OCIA Es la fecha y hora de llegada de entrada para la nueva aparición. OPDUR Es la duración, en horas y minutos, de una operación notificada como completada. OPERR Es el código de error de una operación notificada como finalizada con error. FORM Contiene el número de formulario de la impresora para operaciones en las estaciones de trabajo de impresora. SCLASS Contiene la clase SYSOUT para operaciones en las estaciones de trabajo de impresora. SUBSYS Es el nombre del subsistema del comprobador de seguimiento al que se debe notificar este suceso. Si SUBSYS está en blanco, se IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Utilización de EQQUSINT realiza la difusión del suceso a todos los subsistemas Tivoli Workload Scheduler for z/OS definidos en el sistema z/OS donde se invoca EQQUSINT. EVTIME Contiene la hora del suceso que se está notificando. Si el campo contiene sólo ceros binarios, Tivoli Workload Scheduler for z/OS utiliza la hora actual. EVDATE Contiene la fecha del suceso que se está notificando. Si el campo contiene sólo ceros binarios, Tivoli Workload Scheduler for z/OS utiliza la fecha actual. Si n = 0, año es 19AA. Si n = 1, año es 20AA. RETCODE Lo establece EQQUSINT y puede tener uno de los valores siguientes: 0 Retorno normal. El suceso se ha notificado a Tivoli Workload Scheduler for z/OS. 8 Retorno de error. Existe un error en la información que se ha pasado a EQQUSINT y no se ha notificado ningún suceso a Tivoli Workload Scheduler for z/OS. Notas: 1. Debe especificar valores válidos para los parámetros TYPE y WSNAME y para el parámetro JOBNAME o el parámetro ADID. Los demás valores se pueden inicializar en ceros o en espacios en blanco. 2. OPDUR se procesa sólo si TYPE tiene el valor C. 3. OPERR se procesa sólo si TYPE tiene el valor E. 4. Si no proporciona suficiente información para identificar la operación de forma exclusiva y Tivoli Workload Scheduler for z/OS encuentra más de una operación que coincide con los criterios especificados, Tivoli Workload Scheduler for z/OS determina la operación más aplicable que se debe actualizar. Tivoli Workload Scheduler for z/OS selecciona la operación más aplicable investigando estas características en el orden indicado: a. La operación tiene una prioridad 9. b. La última hora de inicio más temprana. c. Prioridad 8-1. d. La hora de llegada de entrada especificada para la operación, o la llegada de entrada de aparición si la operación no tiene una llegada de entrada definida específicamente. Por lo tanto, si define sólo el parámetro WSNAME y Tivoli Workload Scheduler for z/OS determina que existe más de una operación en el plan actual para esa estación de trabajo en estado R, A, *, S, I o E, la operación con prioridad 9 se actualiza. Si más de una operación especifica prioridad 9, se actualiza la operación con la última hora de inicio más temprana. Si el último inicio es igual, se actualiza la operación con la prioridad más alta. Si la prioridad es igual, se actualiza la operación que especifica la hora de llegada de entrada más temprana. Si la llegada de entrada es igual, se realiza la actualización en función del "primero en llegar, primero es salir". Utilización de EQQUSINW Puede utilizar EQQUSINW para generar un suceso de estado de estación de trabajo para una estación de trabajo determinada que especifique un destino definido por el usuario. Se pueden generar sucesos de estado de estación de trabajo para condiciones activas, anómalas y de fuera de línea. Capítulo 6. Notificación de sucesos 313 Utilización de EQQUSINW Requisitos de invocación EQQUSINW tiene los siguientes requisitos de invocación: APF autorizado, o estado de supervisor o clave PSW 0–7. Autorización Modalidad de unidad que se puede asignar Modalidad de tarea. Amode 24 bits o cualquiera (ANY) si se ha aplicado el APAR PQ74854. Modalidad ASC Registro primario o de acceso (AR). Estado de interrupción Habilitado para E/S e interrupciones externas Bloqueos No se mantiene ningún bloqueo. Parámetros de control Todos los parámetros deben ser direccionables por el emisor de la llamada y estar en el espacio de direcciones primario. Parámetros de EQQUSINW El programa de llamada debe pasar todos estos parámetros a la subrutina. A excepción de STATUS y WSNAME, los parámetros se pueden dejar en blanco. Inicialice RC en cero en la llamada; lo establece EQQUSINW en el retorno. Parámetros de EQQUSINW DUMMY WSNAME 314 DS DS CL8 CL4 STATUS DS STARTOPS DS REROUTE DS ALTWS DS SUBSYS DS CL1 CL1 CL1 CL4 CL4 RC F DS (Parámetro reservado, el valor se ignora) (Se debe especificar el nombre de la estación de trabajo) (Estado de la estación de trabajo) (Acción para operaciones iniciadas o en blanco) (Indicador de redireccionamiento o en blanco) (Nombre de estación de trabajo alternativa o en blanco) (Nombre del subsistema del comprobador de seguimiento o en blanco) (Código de retorno de EQQUSINW) DUMMY Parámetro reservado para utilizarlo más adelante. La subrutina ignora cualquier valor proporcionado. WSNAME Nombre de la estación de trabajo. STATUS Estado A O F STARTOPS Cuando el estado de la estación de trabajo se establece en fuera de línea o anómalo, puede especificar lo que Tivoli Workload Scheduler for z/OS debe hacer con las operaciones que están actualmente en estado iniciado en el destino, o estación de trabajo, donde: R Reinicia automáticamente las operaciones en la estación de trabajo alternativa. L Deja las operaciones en estado iniciado. E Establece todas las operaciones iniciadas en finalizada con error. que desea notificar para la estación de trabajo, donde: Activo Fuera de línea Fallido. IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Utilización de EQQUSINW REROUTE Cuando el estado de la estación de trabajo se establece en fuera de línea o anómalo, puede especificar R para que las operaciones se redireccionen a la estación de trabajo alternativa, o L para que no se realice ningún redireccionamiento; es decir, si desea dejar las operaciones en la estación de trabajo inactiva. ALTWS Cuando el estado de la estación de trabajo se establece en fuera de línea o anómalo, puede especificar una estación de trabajo alternativa donde se deben iniciar las operaciones redireccionadas. SUBSYS Nombre del subsistema del comprobador de seguimiento al que se debe notificar este suceso. Si SUBSYS está en blanco, se realiza la difusión del suceso a todos los subsistemas del comprobador de seguimiento definidos en el sistema z/OS donde se invoca EQQUSINW. RC Lo establece EQQUSINW y puede tener uno de los valores siguientes: 0 Retorno normal. El suceso se ha notificado a Tivoli Workload Scheduler for z/OS. 8 Retorno de error. Existe un error en la información que se ha pasado a EQQUSINW y no se ha notificado ningún suceso a Tivoli Workload Scheduler for z/OS. Nota: Si el valor proporcionado para el parámetro STATUS es igual al estado actual, el suceso se ignora. Se debe proporcionar un valor para los parámetros WSNAME y STATUS. Capítulo 6. Notificación de sucesos 315 Utilización de EQQUSINW 316 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Capítulo 7. Utilización de la comprobación de terminación de trabajo En la siguiente descripción, un trabajo hace referencia a un trabajo por lotes o a una tarea iniciada. IBM Tivoli Workload Scheduler for z/OS utiliza el código de terminación de trabajo para determinar si una operación se ha completado normalmente. El código es el código de retorno más alto de todos los pasos completados o el código de retorno del último paso completado, en función de lo que haya especificado en la palabra clave RETCODE de la sentencia EWTROPTS. Sin embargo, en algunos casos no se puede determinar exclusivamente a partir de este código de retorno si el resultado ha sido satisfactorio o anómalo. En estos casos, puede utilizar la comprobación de terminación de trabajo (JCC) para determinar si un trabajo ha finalizado normalmente. JCC puede explorar el conjunto de datos de SYSOUT de un trabajo determinado y, a continuación, establecer el estado de error, en función de los resultados de esta exploración. Debido a que JCC tiene más información sobre el trabajo, está mejor equipado para decidir si un trabajo ha finalizado normalmente. Consulte “Determinación del éxito o fracaso de un trabajo” en la página 182, que describe cómo Tivoli Workload Scheduler for z/OS determina el siguiente estado de una operación cuando un trabajo o una tarea iniciada finaliza. Nota: La lógica del proceso de JCC no se aplica cuando el trabajo anómalo se ha obtenido reiniciando una operación a nivel de paso o trabajo y la anomalía la determina el paso EQQCLEAN que finaliza con RC>=8. Consulte también “Determinación del éxito o fracaso de un trabajo” en la página 182. Tablas de mensajes de JCC JCC utiliza la palabra clave CHKCLASS que ha especificado en la sentencia JCCOPTS (consulte 81) para decidir qué clases SYSOUT se deben explorar para cada trabajo de finalización. Determine cómo se explorarán los datos de SYSOUT creando tablas de mensajes de JCC. Cada registro del conjunto de datos de SYSOUT se trata como un mensaje. Las tablas de mensajes de JCC determinan la serie de caracteres que se buscará en cada mensaje y qué se debe hacer si se encuentra la serie. Cada tabla de mensajes se define como miembro de la biblioteca EQQJCLIB. JCC utiliza dos tipos de tablas de mensajes: v Cualquier trabajo puede tener una tabla de mensajes específica de trabajo. El nombre del miembro de la biblioteca EQQJCLIB DEBE ser el mismo que el nombre del trabajo. v La tabla de mensajes generales se utiliza para todos los trabajos. La tabla de mensajes generales debe estar ubicada en el miembro EQQGJCCT de la biblioteca EQQJCLIB. La inicialización de JCC fallará si no se puede encontrar la tabla general. Cuando JCC empieza a procesar la salida de un trabajo, se busca en EQQJCLIB para determinar si hay disponible una tabla de mensajes específica de trabajo para este trabajo. Si se encuentra una tabla de mensajes específica de trabajo, se utiliza © Copyright IBM Corp. 1991, 2011 317 Tablas de mensajes de JCC conjuntamente con la tabla de mensajes generales. Cada registro SYSOUT se evalúa respecto a las tablas de mensajes aisladamente, empezando por el primer registro. Primero se utiliza la tabla de mensajes específicos de trabajo y a continuación la tabla de mensajes generales. El registro SYSOUT se evalúa respecto a CADA condición definida en la tabla de mensajes, siempre y cuando CA= no detenga la comprobación. Si se encuentra una coincidencia y la acción de comprobación especifica STOP o ESTOP, no se producirá más proceso de JCC para el trabajo. Si los criterios de coincidencia empiezan por MULTSTA y se encuentra una coincidencia respecto a MULTSTA, JCC no lo trata como una coincidencia hasta que se encuentra una coincidencia para el mismo registro SYSOUT en un MULTMSG subsiguiente. Si MULTSTA coincide, pero no se encuentra ninguna coincidencia de MULTMSG, JCC realiza la acción definida en la entrada de MULTEND correspondiente. Si hay un coincidencia de un valor MULTSTA M=, no se utilizará ningún MULTSTA M= subsiguiente con el mismo valor M=, independientemente de si la acción de comprobación especificaba STOP o ESTOP. Si se encuentra una coincidencia y la acción de comprobación permite que el proceso continúe, o si no se encuentra ninguna coincidencia en las tablas específicas de trabajo o generales, JCC realiza la acción definida en la entrada ENDTAB. Si no hay ninguna entrada ENDTAB, JCC continúa procesando el SYSOUT del registro siguiente. Cuando hay una coincidencia con un NORMMSG o MULTSTA, el registro SYSOUT se consume. Esto significa que no se produce proceso adicional para ese registro SYSOUT. Por lo tanto, si hay una coincidencia en una tabla específica de trabajos, el proceso para ese registro SYSOUT se detiene inmediatamente y no se busca en la tabla general. El proceso continuará en el siguiente registro SYSOUT sólo si CA= permite que la comprobación continúe. El sistema z/OS o un programa de usuario crea un conjunto de datos SYSOUT. Todos los registros se comprueban en conjuntos de datos de SYSOUT creados por el sistema z/OS. El valor de la palabra clave USYSOUT de JCCOPTS determina si se comprueba un conjunto de datos de SYSOUT de usuario. El valor de la palabra clave UMAXLINE determina cuántas líneas del conjunto de datos de SYSOUT de usuario se comprobarán. Todos los registros de todos los conjuntos de datos de SYSOUT se pasan a la salida del comprobador de seguimiento, EQQUX005 (la salida de archivado de SYSOUT). Puede utilizar esta salida para copiar los conjuntos de datos de SYSOUT en un conjunto de datos que resida en un disco o cinta. Notas: 1. JCC es una función del comprobador de seguimiento y, por lo tanto, independiente del contenido del conjunto de datos del plan actual del controlador. JCC procesa todos los trabajos para los que se crea un suceso de terminación de trabajo (3P) en el conjunto de datos de suceso, independientemente de si el trabajo está definido en el plan actual. Para impedir que JCC procese un trabajo o una clase de trabajos, debe utilizar la salida de filtrado de sucesos del comprobador de seguimiento, EQQUX004. 2. Debido a que es posible enviar SYSOUT de trabajos JES2, o partes del SYSOUT, a varios nodos NJE, se podría generar más de un suceso de terminación de trabajo (A3P) para el mismo trabajo. Además, cada suceso podría tener distinta información de código de terminación de trabajo, en función de la salida enviada a un nodo determinado y la comprobación que JCC realiza en ese 318 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Tablas de mensajes de JCC nodo. El estado asignado a la operación depende del suceso A3P que el controlador procese en primer lugar. Por lo tanto, debe asegurarse de que se utiliza el valor FINAL para la palabra clave OUTPUTNODE de la sentencia JTOPTS. FINAL es el valor predeterminado. Si la parte JESYSMSG (anteriormente $SYSMSGS, DSID=4) de SYSOUT se copia en varios nodos de destino finales en los que JCC está activo, o si especifica el valor ANY para OUTPUTNODE, el estado resultante de la operación correspondiente será impredecible. La palabra clave OUTPUTNODE se describe en la página 98. 3. La técnica descrita en la nota 2 no se utiliza en un entorno JES3. Si envía la salida desde un trabajo JES3 a distintos nodos NJE donde JCC está activo, JCC debe realizar la misma comprobación en cada nodo. De lo contrario, el estado resultante de la operación correspondiente será impredecible. Función de registro de incidencias Además de determinar el estado de finalización de los trabajos por lotes explorando los conjuntos de datos de SYSOUT creados por el trabajo, JCC tiene una función de registro de incidencias. JCC se puede dirigir a condiciones de error de registro en un archivo de incidencias. El archivo de incidencias es un archivo secuencial que actualiza un comprobador de seguimiento salida, EQQUX006 (la salida de creación de registro de incidencia). La salida de creación de registro de incidencia es una salida necesaria. Puede utilizar la salida estándar que se proporciona con el comprobador de seguimiento o puede sustituirla por su propia salida. El conjunto de datos del registro de incidencias no es nunca entrada de ninguna función del comprobador de seguimiento. Sólo hace referencia a él la salida de creación de registro de incidencia. Por lo tanto, puede que esté compartido por varias tareas de JCC en ejecución en el mismo sistema o en distintos sistemas. También puede actualizar e incluso volver a asignar los conjuntos de datos manualmente mientras JCC está activo ya que JCC vuelve a asignar el conjunto de datos cada vez que se actualiza. Capítulo 7. Utilización de la comprobación de terminación de trabajo 319 Definición de tablas de mensajes utilizando EQQJCCT Definición de tablas de mensajes utilizando EQQJCCT Puede crear tablas de mensajes ensamblando un archivo de definición de tabla de mensajes consistente en una o más invocaciones a la macro de ensamblador EQQJCCT. La salida del trabajo de ensamblaje es la tabla de mensajes. Debe guardar esta tabla en la biblioteca de tablas de mensajes de JCC. Sintaxis EQQJCCT M= 'texto del mensaje' S= 1 posición de inicio NORMMSG MULTSTA MULTEND MULT2STA MULTMSG SKIPSTA SKIPEND SKIPnnn SKIPDS ENDTAB T= CA= CONT CHECK ERROR ESTOP STOP EID= código de error TID= identificador de seguimiento Cuando codifique la macro EQQJCCT, debe seguir las reglas de sintaxis del lenguaje ensamblador de IBM. Estas reglas requieren que delimite el nombre de la macro, EQQJCCT, mediante uno o más espacios en blanco, que coloca un carácter de continuación (cualquier carácter distinto de blanco) en la columna 72 de cualquier sentencia con una línea de continuación, y que empiece las líneas de continuas en la columna 16. Parámetros M='texto del mensaje' Define una serie de caracteres que JCC intenta encontrar en cada registro SYSOUT. La serie de caracteres se debe colocar entre comillas. El tamaño máximo de la serie es de 51 bytes. Es necesaria la palabra clave M para todos los tipos a excepción de MULTEND o ENDTAB. Ejemplo de M EQQJCCT M='IEF452I' S=posición de inicio|1 Define la posición en el registro SYSOUT del primer carácter de la serie de caracteres del texto del mensaje. Los valores válidos para la posición de inicio van de 0 a 132. El valor 0 indica que el texto del mensaje puede aparecer en cualquier lugar de las primeras 132 posiciones del registro SYSOUT. T=tipo de entrada|NORMMSG Define el tipo de entrada de la tabla de mensajes. Se da soporte a los tipos de entradas siguientes: 320 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Definición de tablas de mensajes utilizando EQQJCCT NORMMSG Tipo de entrada normal. Detiene el proceso del registro SYSOUT actual cuando se encuentra una coincidencia. A continuación, lee el siguiente registro SYSOUT y lo comprueba, empezando de nuevo con la primera entrada de la tabla de mensajes. MULTSTA Inicio de una secuencia de entradas de tabla de múltiples condiciones relacionadas. Debe ir emparejada con una sentencia MULTEND. MULTEND Define la última entrada de una secuencia de entradas de tabla relacionadas iniciada por una entrada MULTSTA. MULT2STA Define una condición adicional que debe cumplir un registro SYSOUT que coincide con una entrada MULTSTA. Solo puede haber una entrada MULT2STA para cada entrada MULTSTA. MULTMSG Define una condición adicional que debe cumplir un registro SYSOUT que coincide con una entrada MULTSTA. Puede haber varias entradas MULTMSG para cada entrada MULTSTA. Si se ha definido una entrada MULT2STA, el registro SYSOUT se trata como una coincidencia solo si cumple las tres condiciones: MULTSTA, MULT2STA y MULTMSG. SKIPSTA Inicio de una secuencia de entradas de definiciones de salto relacionadas. Saltar significa que un registro SYSOUT se lee pero no se comprueba. SKIPSTA debe ir seguido como mínimo por una sentencia SKIPEND. SKIPEND Define cuándo un salto hacia adelante que ha iniciado una entrada SKIPSTA debe finalizar. Puede haber varias entradas SKIPEND para cada entrada SKIPSTA. El salto se detiene cuando se encuentra un registro SYSOUT que coincide con una de las entradas SKIPEND. SKIPnnn Define un salto hacia adelante de un número fijo de registros. El número se especifica como nnn en la palabra clave SKIPnnn. El número nnn debe tener 3 dígitos, de 001 a 999. SKIPDS Define un salto hacia adelante de los demás registros del conjunto de datos de SYSOUT actual. ENDTAB Define cómo se tratarán los registros que no tienen coincidencias con entradas de tabla anteriores. Si se especifica, la entrada ENDTAB debe ser la última entrada de una definición de tabla de mensajes. A continuación se muestran algunos ejemplos del parámetro T: Ejemplo 1 de T EQQJCCT S=1,M=’IEF375I’ En el ejemplo 1 se muestra el valor predeterminado utilizado para entradas de mensajes normales. Capítulo 7. Utilización de la comprobación de terminación de trabajo 321 Definición de tablas de mensajes utilizando EQQJCCT Ejemplo 2 de T EQQJCCT EQQJCCT EQQJCCT EQQJCCT EQQJCCT T=MULTSTA,S=1,M=’IEF285I’ DEALLOCATION T=MULTMSG,S=56,M=’KEPT’ T=MULTMSG,S=56,M=’DELETED’ T=MULTMSG,S=56,M=’UNCATALOGED’ T=MULTEND En el ejemplo 2, se explora la línea SYSOUT para ver si contiene IEF285I. Si se encuentra IEF285I, se explora la línea SYSOUT para ver si contiene KEPT, DELETED y UNCATALOGED. Ejemplo 3 de T EQQJCCT EQQJCCT EQQJCCT EQQJCCT T=MULTSTA,S=1,M=’IEC501’ MOUNT T=MULT2STA,S=0,M=’PRIVAT’ T=MULTMSG,S=0,M=’GDG’,CA=ESTOP T=MULTEND En el ejemplo 3, la línea SYSOUT se explora para ver si contiene IEC501. Si se encuentra IEC501, se explora también la línea SYSOUT para ver si contiene PRIVAT. Si se encuentra IEC501 y PRIVAT, se explora la línea SYSOUT para ver si contiene GDG. Ejemplo 4 de T EQQJCCT S=49,T=SKIPSTA,M=’J E S 2 J O B L O G’ EQQJCCT S=1,T=SKIPEND,M=’ICH0001I’ (RACF LAST ACCESS) EQQJCCT S=20,T=SKIPEND,M=’IEF452I’,CA=STOP (JOB NOT RUN-JCL ERR) En el ejemplo 4, cuando se inicia el registro de JES2, la comprobación de los registros SYSOUT se pasa por alto hasta que se encuentra ICH0001I o IEF452I en la línea SYSOUT. Ejemplo 5 de T EQQJCCT S=49,T=SKIP007,M=’J E S 2 J O B L O G’ En el ejemplo 5 se muestra cómo puede saltarse los siguientes 7 registros que siguen a un registro que contiene J E S 2 J O B L O G. Ejemplo 6 de T EQQJCCT T=ENDTAB,CA=CONT En el ejemplo 6, un registro SYSOUT que no coincide con ninguna entrada de la tabla de mensajes se acepta como normal. 322 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Definición de tablas de mensajes utilizando EQQJCCT Ejemplo 7 de T EQQJCCT T=ENDTAB,CA=ESTOP En el ejemplo 7, si un registro SYSOUT no coincide con ninguna entrada de la tabla de mensajes se genera un error. CA=acción de comprobación|CONT Define la acción que debe realizar JCC cuando se encuentra un registro SYSOUT que cumple las condiciones definidas por la entrada de tabla actual. Se da soporte a las acciones siguientes: CONT Continua la comprobación. Detiene el proceso del registro SYSOUT actual (porque coincide). A continuación, lee el siguiente registro SYSOUT y lo comprueba, empezando de nuevo por la primera entrada de la tabla de mensajes. CHECK Comprueba la siguiente entrada de tabla. Además, comprueba el registro actual respecto a la siguiente entrada de tabla. ERROR Se ha detectado una condición de error. Continúa la comprobación, pero trata este trabajo como finalizado con error. ESTOP Se ha detectado una condición de error. Detiene la comprobación, pero trata este error como finalizado con error. STOP Detiene la comprobación. Detiene el proceso del registro SYSOUT actual; lee los demás registros SYSOUT pero no comprueba su contenido. A continuación se muestran algunos ejemplos del parámetro CA: Ejemplo 1 de CA EQQJCCT M=’IEF287I’,CA=ERROR,EID=5555 En el ejemplo 1 se muestra cómo señalar un trabajo como finalizado con error, con un código de error de 5555, si cualquier paso del trabajo emite el mensaje IEF287I. Ejemplo 2 de CA EQQJCCT M=’B2 TABLE MISSING’,CA=ESTOP,EID=1111 El ejemplo 2 es un mensaje específico de trabajo. JCC indica el error a Tivoli Workload Scheduler for z/OS y detiene la comprobación adicional de la salida del mensaje del trabajo. Ejemplo 3 de CA EQQJCCT S=1,T=SKIPSTA,M=’IDCAMS SYSTEM SERVICES’ EQQJCCT S=1,T=SKIPEND,M=’IDC0002I’,CA=CHECK EQQJCCT S=57,T=NORMMSG,M=’CODE WAS 16’,CA=ERROR Capítulo 7. Utilización de la comprobación de terminación de trabajo 323 Definición de tablas de mensajes utilizando EQQJCCT En el ejemplo 3, se inicia el salto cuando se encuentra IDCAMS SYSTEM SERVICES en la línea SYSOUT. Cuando se encuentra IDC0002I en el registro SYSOUT, se detiene el salto y se indica una condición de error si se encuentra este texto en la línea SYSOUT: CODE WAS 16. EID=código de error| Define un código de error que utilizará el seguimiento de trabajos de Tivoli Workload Scheduler for z/OS. El código de error es un número decimal de 4 dígitos o 3 dígitos hexadecimales precedidos por el carácter X. El código de error predeterminado consiste en 4 caracteres en blanco. Si no hay ningún código de error, JCC no cambia el estado del trabajo. Sólo se puede definir un código de error cuando la acción de comprobación actual es ERROR o ESTOP. JCC normalmente crea un registro de incidencia para todas las acciones ERROR y ESTOP con coincidencias. Sin embargo, el código de error 0000 impide la creación de un registro de incidencia. De forma similar, el código de error predeterminado, 4 espacios en blanco, hace que se cree una incidencia, pero impide que el seguimiento de trabajos trate la coincidencia como un error real. A continuación se muestra un ejemplo de cómo utilizar el parámetro EID=: Ejemplo de EID EQQJCCT EQQJCCT EQQJCCT EQQJCCT EQQJCCT CA=ERROR,EID=XB37,M=’IEC030I’ CA=ERROR,EID=XD37,M=’IEC031I’ CA=ERROR,EID=XE37,M=’IEC032I’ CA=ERROR,EID=892,M=’IEF257’ (SPACE NOT FOUND) CA=ERROR,M=’DATABASE IS 80% FULL’ En este ejemplo se muestra cómo emparejar los códigos de error y los mensajes que se imprimirán. Si especifica CA=ERROR o ESTOP pero no especifica EID (como en la última línea del ejemplo), el código de error consistirá en 4 espacios en blanco. En este caso, no se notifica al seguimiento de trabajos sobre el error, pero se graba un registro en el archivo de incidencias. Puede utilizar este método para registrar incidencias que no afectan actualmente al proceso normal de trabajos pero que se deben investigar posteriormente. TID=identificador de seguimiento| Define un identificador de seguimiento que se puede utilizar en el registro de incidencias para agrupar errores similares con una identificación común El identificador de seguimiento es una serie de caracteres con un máximo de 8 caracteres. El identificador predeterminado consiste en 8 caracteres de espacio en blanco. Ejemplo de TID EQQJCCT CA=ERROR,EID=XB37,TID=SPACE,M=’IEC030I’ EQQJCCT CA=ERROR,EID=XD37,TID=SPACE,M=’IEC031I’ EQQJCCT CA=ERROR,EID=XE37,TID=SPACE,M=’IEC032I’ En este ejemplo se muestra cómo asegurar que el error se registra en el archivo de incidencias y cómo correlacionar el mismo comentario con distintos errores. Tabla de mensajes de ejemplo Las macros siguientes generan una tabla de mensajes generales que puede utilizar para evitar la mayoría de las comprobaciones manuales de JCL. Las excepciones de 324 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Definición de tablas de mensajes utilizando EQQJCCT los trabajos individuales se especifican en las tablas de mensajes específicos de trabajos, que no se muestran aquí. Si tiene estándares detallados de los códigos de terminación, sólo necesite algunas tablas de mensajes específicos de trabajo. Macros de tabla de mensajes ( 1) EQQJCCT CA=ESTOP,EID=5555,M=’IEF287I’,TID=NOTCTLGX ( 2) EQQJCCT CA=ESTOP,EID=4444,M=’DATASET LIMIT REACHED’, S=0,TID=REORG-DB ( 3) EQQJCCT CA=ESTOP,EID=0012,M=’COND CODE 0012’,S=0,TID=RC12 ( 4) EQQJCCT CA=ERROR,M=’ICE061A’,S=21,TID=IOERROR ( 5) EQQJCCT T=MULTSTA,M=’IEC501’,S=20 MOUNT PRIVATE ( 6) EQQJCCT T=MULTMSG,M=’PRIVAT’,S=34,CA=ESTOP,EID=6666,TID=PRIVATE ( 7) EQQJCCT T=MULTEND ( 8) EQQJCCT T=MULTSTA,M=’COND CODE 0016’,S=0 ( 9) EQQJCCT T=MULTMSG,M=’IBTS’,S=0,CA=ERROR,EID=0000,TID=OK-IBTS (10) EQQJCCT T=MULTMSG,M=’GISFR’,S=0,CA=ERROR,EID=0000,TID=OK-GIS (11) EQQJCCT T=MULTEND,CA=ESTOP,EID=0016,TID=RC16 (12) EQQJCCT S=0,T=NORMMSG,M=’SPOOL DATASET IS FULL’,EID=0016, TID=IBTSFULL,CA=ESTOP END X X Sentencia (1) Detecta el mensaje IEF287I, que indica una situación de trabajo no catalogado 2. El seguimiento de trabajos de Tivoli Workload Scheduler for z/OS lo considera como finalizado con error, con el código de error 5555. Sentencia (2) Avisa que la base de datos de IMS está llena. El trabajo se establece como finalizado con error debido a que los trabajos sucesivos a este trabajo nunca pueden terminar satisfactoriamente. Sentencia (3) Trata cada COND CODE 0012 como una condición de finalizado con error. La indicación de error detectada por el seguimiento de trabajos se restablece si los demás pasos después del error no se desechan. Esta definición puede ahorrar los esfuerzos de actualizar el JCL anterior a un estándar común. Todos los trabajos que tienen un paso que tiene como resultado COND CODE 0012 generan una incidencia en el registro de incidencias. Sentencia (4) Registra todos los errores de E/S de ordenación/fusión en el archivo de incidencias. Tivoli Workload Scheduler for z/OS detecta si se recupera el error de E/S, de forma que no se especifica ningún EID. Sentencias (5-7) Define todos los MOUNT o PRIVAT como errores. Sentencias (8-12) Juntas, estas sentencias definen que COND CODE 0016 es normalmente incorrecto. Sin embargo, si se encuentra el mensaje IBTS o el mensaje GISFR en la línea (forma siempre parte del nombre de paso en esta instalación), es un error sólo si también se encuentra SPOOL data set IS FULL. Sentencias (9-10) Definen que este trabajo es correcto, incluso si el seguimiento de trabajos de Tivoli Workload Scheduler for z/OS ha detectado un error a partir de la información recopilada del sistema. Si no se encuentra ninguna coincidencia, la Capítulo 7. Utilización de la comprobación de terminación de trabajo 325 Definición de tablas de mensajes utilizando EQQJCCT sentencia (11) se procesa. Esto dará como resultado EID = 0016 a Tivoli Workload Scheduler for z/OS ya que se ha encontrado COND CODE 0016 y no era IBTS ni GISFR. Sentencia (12) Define una excepción a la excepción. Aunque COND CODE 0016 normalmente es incorrecto, es correcto para trabajos IBTS. Sin embargo, un trabajo IBTS COND CODE 0016 es incorrecto si se encuentra posteriormente SPOOL data set IS FULL en la exploración. 326 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Capítulo 8. Utilización del almacén de datos El rol del almacén de datos de Tivoli Workload Scheduler for z/OS es almacenar localmente una copia de los datos de SYSOUT generados por los trabajos enviados. Estos datos se transmiten de vuelta al controlador de Tivoli Workload Scheduler for z/OS sólo cuando se solicitan, es decir, sólo cuando son necesarios para las acciones de reinicio y limpieza o cuando se solicita explícitamente su exploración. En un entorno z/OS, el almacén de datos ya debe estar instalado antes de poder realizar la recuperación del registro de trabajos o el reinicio y limpieza. El almacén de datos automáticamente se limpia a sí mismo con la frecuencia especificada por el usuario, según los criterios del usuario, a fin de evitar crecer en exceso. Cuando la misma operación requiere varios reinicios, a fin de almacenar sólo las salidas del sistema necesarias por el reinicio y la limpieza para optimizar el acceso a los datos, un componente del almacén de datos, denominado Base de datos, se activa en el controlador. Como parte del controlador, este componente se denomina almacén de datos local. Dentro del almacén de datos local las operaciones de limpieza interna están sincronizadas con la ampliación del plan actual. Visión general El almacén de datos se ejecuta en un espacio de direcciones aparte y está dedicado al almacenamiento y posible recuperación de conjuntos de datos de SYSOUT pertenecientes a los trabajos enviados. Las características principales del nuevo soporte del almacén de datos se listan a continuación: v Se debe instalar un almacén de datos para cada agrupación de JES en un sistema. En una configuración de JES simple, esto significaría un almacén de datos para cada comprobador de seguimiento. En sistemas con almacenamientos compartidos (por ejemplo, JES2 MAS), habrá un almacén de datos para cada agrupación y habrá menos almacenes de datos que comprobadores de seguimiento. v Es necesario que el almacén de datos tenga un destino de salida específico. Este destino lo debe utilizar sólo el almacén de datos, que seleccionará la salida del sistema, según este tipo de filtro. Tenga en cuenta que el destino reservado es exclusivo dentro de un controlador o almacén de datos de configuración del almacén de datos. El destino de salida se utiliza para duplicar las salidas del sistema que se almacenarán en la base de datos del almacén de datos. v Una vez que se ha completado el almacenamiento, las salidas del sistema duplicadas se suprimirán. v La comunicación entre el controlador y el almacén de datos es análoga a la comunicación controlador/comprobador de seguimiento, aunque el método de DASD compartido que es posible para la comunicación controlador/ comprobador de seguimiento no es posible para la comunicación controlador/almacén de datos. El tipo de almacén de datos se puede definir como SNA o XCF, pero el mismo controlador puede conectarse a almacenes de datos XCF y SNA. Se deben utilizar valores distintos de LU y XCF para conexiones controlador/comprobador de seguimiento y controlador/almacén de datos. El controlador se identifica mediante dos valores de LU distintos: uno © Copyright IBM Corp. 1991, 2011 327 Visión general para los almacenes de datos y uno para los rastreadores. Todos los almacenes de datos funcionan en un destino reservado, que debe tener siempre el mismo nombre. Las siguientes subtareas del controlador manejan la comunicación con el almacén de datos: tarea FL Tarea de captación de salida del sistema (incluye también la comunicación XCF) tarea FN Tarea de comunicación SNA de FL (se inicia sólo si se utiliza comunicación SNA) Además, en el componente del almacén de datos local, existen las mismas subtareas que se incluyen en la base de datos del almacén de datos principal: el índice primario, el índice secundario, los archivos de datos y las subtareas de manejo de errores. En la figura siguiente se muestra un ejemplo de configuración de almacén de datos: 328 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Requisitos previos Base de datos del almacén de datos local Z/OS 2 Z/OS 1 Rastreador 3 Rastreador 1 + Controlador + Almacén de datos local Datos Almacén 3 Datos Almacén 1 Almacén de datos Base de datos 3 Destino salida del planificador JES1 Destino salida del planificador JES1 Almacén de datos Base de datos 1 Conexión controlador con almacén de datos ( SNA o XCF ) Conexión controlador con rastreador Figura 4. Controlador, rastreador y almacén de datos - vista esquemática Requisitos previos La función del almacén de datos se puede utilizar sólo si se cumplen los requisitos previos siguientes: v El destino de salida está dedicado al almacén de datos v La palabra clave OUTPUTNODE (FINAL) se especifica en el parámetro de inicialización JTOPTS. Capítulo 8. Utilización del almacén de datos 329 Instalación del almacén de datos Instalación del almacén de datos Se debe instalar un almacén de datos para cada agrupación de JES implicada en la configuración del controlador/comprobador de seguimiento. Para instalar el almacén de datos debe hacer lo siguiente: v Cree e inicialice la base de datos del almacén de datos. Esta actividad consta de los pasos siguientes: 1. Ejecute EQQJOBS Clist para crear ejemplos del almacén de datos 2. Calcule los tamaños del archivo de VSAM del almacén de datos 3. Asigne los archivos de VSAM del almacén de datos 4. Inicialice los archivos de VSAM v Configure el almacén de datos. Esto implica lo siguiente: 1. Especificar los valores de los parámetros de inicialización del almacén de datos 2. Especificar los valores de los parámetros para la comunicación con el controlador v Activar el almacén de datos – Crear el trabajo de inicio para el espacio de direcciones del almacén de datos Ejecución de EQQJOBS para crear ejemplos de instalación Ejecute el nuevo EQQJOBS clist. La opción Crear ejemplos del almacén de datos ahora crea el siguiente conjunto de ejemplos: EQQPCS04 Para definir los archivos de VSAM del almacén de datos y para inicializarlos EQQPCS07 Para asignar conjuntos de datos de VSAM de reinicio y limpieza EQQDSCL Para ejecutar el programa de utilidad de limpieza por lotes (los parámetros de entrada se toman de EQQDSCLP) EQQASEX Para ejecutar el programa de utilidad de exportación por lotes (los parámetros de entrada se toman de EQQDSEXP) EQQDSIM Para ejecutar el programa de utilidad de importación por lotes (los parámetros de entrada se toman de EQQDSIMP) EQQDSRI Para ejecutar el programa de utilidad de recuperación de índice por lotes (los parámetros de entrada se toman de EQQDSRIP) EQQDSRG Para ejecutar el programa de utilidad reorg por lotes (los parámetros de entrada se toman de EQQDSEXP y EQQDSIMP) EQQCLEAN Procedimiento de ejemplo que implica el programa EQQCLEAN EQQDST Procedimiento de inicio del almacén de datos de ejemplo (los parámetros de entrada se toman de EQQDSTP) 330 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Estimación del tamaño de los archivos de datos de VSAM Estimación del tamaño de los archivos de datos de VSAM del almacén de datos La base de datos de SYSOUT del almacén de datos consta de VSAM: v Archivos de datos para datos estructurados y no estructurados v Índice primario v Índice secundario Archivos de datos El almacén de datos distingue los tipos de archivos de datos (DD) de VSAM por sus nombres: los DD estructurados se denominan EQQSDFnn; los DD no estructurados se denominan EQQUDFnn. Aunque la estructura del archivo de datos para estos dos tipos es la misma, su contenido y finalidad son distintos, como se describe a continuación. Archivos de datos no estructurados Los archivos de datos no estructurados contiene las SYSOUT en formato plano, tal y como las proporciona la agrupación de JES. Puede comprobar la SYSOUT con la función EXAMINAR ANOTACIONES DE TRABAJO. Tenga en cuenta que el archivo de datos no estructurado puede almacenar, si se solicita, también las SYSOUT de usuario. La activación de los archivos de datos no estructurados es opcional, en función de los parámetros adecuados del almacén de datos. En un archivo de datos no estructurado, cada SYSOUT, consistente en n registros lógicos, toma como mínimo una página de datos (4096 bytes). El tamaño del archivo de datos de VSAM depende de los factores siguientes: v El tamaño típico de la SYSOUT para trabajos que se deben almacenar (considere también el parámetro MAXSTOL que especifica el número de líneas de la SYSOUT de usuario que se almacenarán) v El número promedio de trabajos que se ejecutan cada día v El periodo de retención de los registros de trabajos en almacén de datos v El número de archivos de datos que desea crear (de 1 a 99) Puede calcular el número de páginas que necesita de la forma siguiente: v Calcule el número máximo de registros de trabajos que pueden estar almacenados en un momento determinado. Para ello, multiplique el número de trabajos en ejecución en un día por el número de días que desea que los registros de trabajos estén disponibles. v Calcule el número promedio de páginas que son necesarias para cada registro de trabajos. Éste depende del número promedio de líneas en cada SYSOUT y de la longitud promedio de línea de SYSOUT. Como mínimo una página es necesaria para cada registro de trabajos. v Calcule el número total de páginas necesarias. Para ello, multiplique el número de registros de trabajos almacenados de forma simultánea por el número promedio de página para cada SYSOUT. v Calcule el número de páginas necesarias para cada archivo. Para ello, divida el resultado anterior entre el número de archivos de datos que desea crear. v Determine el tamaño de cada archivo de datos según el tipo de soporte y la unidad de espacio de la instalación. Capítulo 8. Utilización del almacén de datos 331 Estimación del tamaño de los archivos de datos de VSAM Ejemplo del cálculo para archivos de datos no estructurados: Una empresa ejecuta 1000 trabajos cada día en un único sistema y cada trabajo genera aproximadamente 4000 líneas de datos de SYSOUT. La mayoría de las líneas tienen una longitud de 80 caracteres. Las acciones de reinicio y limpieza se realizan casi inmediatamente en caso de que un trabajo falle, y de esta forma no es necesario mantener registros en el almacén de datos durante más de 1 día. Se toma la decisión de dividir los datos entre 10 archivos. El número máximo de registros almacenados en un momento determinado 1 es: 1000 * 1 = 1000. Debido a que cada registro tiene aproximadamente una longitud de 4000 líneas, y a que cada línea tiene aproximadamente una longitud de 80 caracteres, el número de bytes de espacio necesario para cada uno es: 4000 * 80 = 320.000. Por lo tanto, el número total de bytes de espacio necesario es: 320.000 * 1000 = 320.000.000 Si se utilizan 4 archivos, cada archivo contendría el siguiente número de bytes de datos: 320.000.000 / 4 = 80.000.000. Si se ha utilizado DASD 3390, cada archivo requeriría este número de pistas: 80.000.000 / 56664 = 1412 o este número de cilindros: 80.000.000 / 849960 = 94 Archivos de datos estructurados Los archivos de datos estructurados contienen las SYSOUT de registros de trabajos en un formato basado en el análisis de los tres componentes del registro de trabajos, JESJCL, JESYSMSG y JESMSGLG, especialmente los dos primeros. Las SYSOUTS de usuario se excluyen de la modalidad de estructuración. Cada registro de trabajos almacenado consta de dos partes diferenciadas: v Un número de páginas, cada una de las cuales consta de 4096 bytes dedicados en el JCL ampliado v Un número de páginas dedicadas en un conjunto completo y ordenado jerárquicamente de elementos estructurados para las funciones de reinicio y limpieza. Por lo tanto, el número mínimo de páginas utilizado por una SYSOUT estructurada es 2 y el uso medio de espacio depende de la complejidad del trabajo. Para determinar la dimensión óptima de los archivos de datos estructurados, siga las instrucciones proporcionadas para la asignación del archivo de datos no estructurado, pero tenga en cuenta que las SYSOUT de usuario no están presentes. Para las SYSOUT estructuradas de tamaño medio, aplique los criterios utilizados para el registro de trabajos no estructurado: el requisito mayor de memoria de las SYSOUT pequeñas estructuradas, en comparación con el correspondiente formato no estructurado, se equilibra por el requisito mayor de memoria del formato no estructurado cuando aumenta la complejidad de la SYSOUT. Índice primario Cada fila del archivo del índice primario tiene una longitud fija de 77 caracteres. Cada fila puede representar un conjunto de datos de SYSOUT de usuario o los tres conjuntos de datos de SYSOUT de z/OS (JESMSGLG, JESJCL y JESSYSMSG). Cada fila contiene una clave que muestra el nombre de archivo, ID de trabajo, fecha de lector de inicio y hora de lector de inicio, que apunta a los datos almacenados en los archivos de datos. Para establecer el tamaño correcto del archivo de índice primario de VSAM, multiplique el número promedio de conjuntos de datos de SYSOUT por trabajo por el número máximo de trabajos almacenados de forma simultánea en la base de datos. Este valor es el número máximo de filas en el índice primario; se debe aumentar en un margen adecuado para que pueda asumir horas punta de la carga de trabajo y permitir su crecimiento. 332 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Estimación del tamaño de los archivos de datos de VSAM Para buscar la cantidad total de espacio que se debe asignar al índice primario de VSAM, debe multiplicar este número máximo de filas ajustado por la longitud total del registro. Ejemplo La gran mayoría de los 1000 trabajos ejecutados diariamente por la misma empresa del ejemplo anterior genera un único conjunto de datos de SYSOUT de usuario, junto con los conjuntos de datos habituales del sistema. Por lo tanto, el número máximo de filas del índice es: 2 * 1000 = 2000. Permitiendo un 50% de crecimiento, el espacio necesario para el índice es: 3000 * 77 = 231000 bytes. En un 3390, esto es 231000 / 56664 = 4 pistas. Índice secundario El índice secundario es un conjunto de datos secuencial de claves de longitud variable (KSDS). Debido a que puede ser un único registro, que corresponde a un valor de clave secundaria específico, puede rastrear muchas claves primarias. Actualmente, un valor de clave secundaria se asocia sólo con una única clave primaria y, por este motivo, cada SYSOUT en el índice secundario requiere una fila de 76 caracteres. Para establecer el tamaño del archivo de índice secundario de VSAM, realice los pasos siguientes: 1. Multiplique el número promedio de conjuntos de datos de SYSOUT para cada trabajo por el número máximo de trabajos almacenados actualmente en la base de datos. El resultado es el número máximo de filas en el índice secundario. 2. Aumente este valor para que pueda asumir horas punta de carga de trabajo y permitir el crecimiento. 3. Multiplique este valor ajustado por la longitud total del registro. Esto proporciona el espacio total que se debe asignar para el índice secundario de VSAM. Características del almacén de datos local Los criterios para establecer el tamaño del almacén de datos local de VSAM difieren de los del almacén de datos principal. Por lo tanto, tenga en cuenta lo siguiente: v Sólo las SYSOUT del almacén de datos principal que se puedan reiniciar y limpiar también se almacenan en el almacén de datos local. v Debido a que los datos no estructurados no se van a reiniciar y limpiar, el almacén de datos local requiere considerablemente menos espacio. Asignación de VSAM de almacén de datos En esta sección se describe lo que se debe hacer para asignar los archivos de VSAM necesarios para el almacén de datos. El miembro de ejemplo EQQPCS04 contiene el JCL para asignar estos archivos. Archivos de datos Puede crear hasta 99 archivos de datos estructurados y hasta 99 archivos de datos no estructurados. Cada uno de ellos se debe identificar mediante un ddname exclusivo en el trabajo de inicio del almacén de datos. A continuación se muestra un ejemplo de la creación de un archivo de datos estructurados y no estructurados: Capítulo 8. Utilización del almacén de datos 333 Asignación de VSAM de almacén de datos //STRUCT //SYSPRINT //EQQSDF01 //SYSIN DELETE DEFINE //UNSTRUCT //SYSPRINT //EQQUDF01 //SYSIN DELETE DEFINE EXEC PGM=IDCAMS DD SYSOUT=* DD UNIT=SYSDA,VOL=SER=S25PRA,DISP=OLD DD * OPCDEV1.SDF01 CLUSTER (NAME(OPCDEV.SDF01) VOLUMES(S25PRA) TRACKS(1,1) SHAREOPTIONS(2,3) LINEAR) EXEC PGM=IDCAMS DD SYSOUT=* DD UNIT=SYSDA,VOL=SER=S25PRA,DISP=OLD DD * OPCDEV1.UDF01 CLUSTER (NAME(OPCDEV.UDF01) VOLUMES(S25PRA) TRACKS(1,1) SHAREOPTIONS(2,3) LINEAR) Índice primario Debe definir un índice primario para cada almacén de datos e inicializarlo con un registro de cabecera. A continuación se muestra un ejemplo de JCL para el descartar y crear el archivo de índice primario: //DELPKI EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* DELETE OPCDEV.PKI0X CLUSTER PURGE //*---------------------------------------------------------------//DEFPKI EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSIN DD * DEFINE CLUSTER(NAME(OPCDEV.PKI0X)CYLINDERS(2,1)VOLUMES(S25PRA)KEYS(34,0)RECORDSIZE(77,77)CISZ(4096)UNIQUEINDEXEDSHR(1,3)FREESPACE(10,10)) Índice secundario Debe definir un índice secundario para cada almacén de datos e inicializarlo con un registro de cabecera. A continuación se muestra un ejemplo de JCL para el descartar y crear el archivo de índice secundario: //DELSKI EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* DELETE OPCDEV.SKI0X CLUSTER PURGE //*---------------------------------------------------------------//DEFSKI EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSIN DD * DEFINE CLUSTER(NAME(OPCDEV.SKI0X)CYLINDERS(2,1)VOLUMES(S25PRA)KEYS(40,0)- 334 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Asignación de VSAM de almacén de datos RECORDSIZE(76,32000)CISZ(4096)UNIQUEINDEXEDSHR(1,3)FREESPACE(10,10)) Inicialización de archivos de VSAM de almacén de datos En esta sección se describen los pasos necesarios para inicializar archivos de VSAM utilizados por el almacén de datos. El miembro de ejemplo EQQPCS04 contiene JCL para realizar esta tarea. Archivos de datos No es necesario inicializar los archivos de datos; se formatean automáticamente la primera vez que se inicia el almacén de datos. Índice primario Cada archivo de índice primario se debe inicializar con un registro de cabecera: POS 1 - 8 POS 9 - 16 POS 17 - 77 espacio en blanco ’00010101’ ’b (ceros binarios) A continuación se muestra un ejemplo de JCL que inicializa el registro de cabecera de un archivo de índice primario. Se puede ejecutar por separado o se puede añadir al trabajo que crea los archivos de VSAM. //INIPKI EXEC PGM=SORT //SYSOUT DD SYSOUT=* //SORTIN DD * 00010101 /* //SORTOUT DD DSN=OPCDEV2.RES.PKI0X,DISP=SHR //DFSPARM DD * RECORD TYPE=V SORT FIELDS=(1,16,CH,A) OUTREC FIELDS=(9:C’00010101’,61Z) Índice secundario Cada archivo de índice secundario se debe inicializar con un registro de cabecera que tenga la longitud mínima de registro, 76 caracteres, establecidos todos ellos en ceros binarios. A continuación se muestra un ejemplo de JCL que inicializa el registro de cabecera de un archivo de índice secundario. Se puede ejecutar por separado o se puede añadir al trabajo que crea los archivos de VSAM. //*---------------------------------------------------------------* //* PREPARE HEADER RECORD //*---------------------------------------------------------------* //INIT01 EXEC PGM=SORT //SYSOUT DD SYSOUT=* //SORTIN DD * 0/* //SORTOUT DD DSN=OPCDEV2.RES.SKIHDR,DISP=(NEW,CATLG),UNIT=SYSDA, DCB=(RECFM=F,LRECL=76,BLKSIZE=76),SPACE=(TRK,(1)) //DFSPARM DD * RECORD TYPE=F SORT FIELDS=(1,1,CH,A) OUTREC FIELDS=(76X'00') //*---------------------------------------------------------------* Capítulo 8. Utilización del almacén de datos 335 Inicialización de archivos de VSAM de almacén de datos /* INITIALIZE SECONDARY INDEX //*---------------------------------------------------------------* //INIT02 EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSIN DD * REPRO INDATASET(OPCDEV2.RES.SKIHDR)OUTDATASET(OPCDEV2.RES.SKI0X) //*---------------------------------------------------------------* //* DELETE INPUT FILE //*---------------------------------------------------------------* //INIT03 EXEC PGM=IEFBR14 //SORTOUT DD DSN=OPCDEV2.RES.SKIHDR,DISP=(OLD,DELETE,DELETE) Acciones posteriores a la instalación en los archivos de VSAM de almacén de datos Mientras que es necesario inicializar los índices primarios y secundarios, los archivos de datos se inicializan automáticamente durante el inicio del almacén de datos. Para añadir un nuevo archivo de datos, créelo y añádalo al procedimiento de inicio del almacén de datos. Sin embargo, una vez que un archivo de datos se ha inicializado, éste no se puede eliminar del procedimiento. Para volver a asignar un archivo de datos, se deben volver a asignar también los índices primarios y secundarios. Cuando se llenen los archivos de datos locales y remotos de VSAM: 1. Realice una copia de todos los archivos de datos y de los índices primarios y secundarios en archivos temporales utilizando la función REPRO de IDCAMS. 2. SUPRIMA y DEFINA clústeres, para aumentar el espacio asignado. 3. Utilice la función REPRO para copiar los archivos temporales en los nuevos archivos de VSAM asignados. 4. Si es necesario, defina nuevos archivos de datos y añádalos al procedimiento del almacén de datos. Los archivos de datos se inicializarán la primera vez que se inicie el almacén de datos. En lugar de IDCAMS, también puede utilizar los programas de utilidad de EXPORTACIÓN e IMPORTACIÓN. Este método es más lento pero reorganiza también los archivos de datos. La reorganización de los archivos de datos significa que se recupera todo el espacio perdido, aunque esto no tiene ningún efecto en los rendimientos del almacén de datos. Para reducir el número de archivos de datos, utilice los programas de utilidad de EXPORTACIÓN e IMPORTACIÓN. Después de la fase de EXPORTACIÓN, puede SUPRIMIR y DEFINIR clústeres y reducir su número. Cuando se dañe un índice primario o secundario, utilice el programa de utilidad de RECUPERACIÓN que, empezando por los archivos de datos, los reconstruye. La recuperación del índice primario y del índice secundario se inicia en el mismo programa de utilidad, que lee los archivos de datos para recuperar primero el índice primario. Configuración del almacén de datos Las secciones siguientes contienen un ejemplo de las sentencias DSTOPTS y FLOPTS que necesita para configurar el almacén de datos. Para ver ejemplos detallados sobre la configuración del almacén de datos, consulte la publicación IBM Tivoli Workload Scheduler for z/OS Installation Guide. 336 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Configuración del almacén de datos Sentencias de inicialización del almacén de datos Las sentencias de inicialización del almacén de datos se codifican en un miembro del conjunto de datos particionados especificado por la sentencia EQQPARM DD en el JCL de inicio. El miembro se identifica mediante un parámetro PARM de la sentencia EXEC. EQQDSTP se proporciona como un miembro de inicialización del almacén de datos de ejemplo. A continuación se muestra un ejemplo de una configuración simple del almacén de datos: DSTOPTS HOSTCON(SNA) MAXSTOL(0) NWRITER(3) SYSDEST(OPC2) STOUNSD(Y) QTIMEOUT(15) WINTERVAL(15) DSTLUNAM(I9PC45A3) CTLLUNAM(I9PC45R3) DELAYTIME(15) CINTERVAL(60) CLNPARM(EQQCLNPA) HDRJOBNAME(JOBNAME) HDRSTEPNAME(STEPNAME) HDRPROCNAME(PROCSTEP) HDRJOBLENGTH(21) HDRSTEPLENGTH(30) HDRPROCLENGTH(39) Establecimiento de las sentencias de inicialización del controlador/rastreador UP Las sentencias de inicialización de tarea FL (solicitante de registro de trabajos) se definen en el mismo miembro que las sentencias de inicialización del controlador actual mediante la sentencia FLOPTS. Los miembros de ejemplo EQQCONP y EQQCONOP contienen ejemplos de estas sentencias. A continuación se muestra un ejemplo de una sentencia FLOPTS simple: FLOPTS CTLLUNAM(I9PC45R3) SNADEST(I9PC45T3.I9PC45A3) Consideraciones sobre las sentencias RCLOPTS Las opciones utilizadas por el controlador durante las funciones de reinicio y limpieza se definen con las sentencias RCLOPTS (los miembros de ejemplo EQQCONP y EQQCONOP contienen ejemplos de esta sentencia). Debido a que en algunos casos es posible que EQQCLEAN suprima un conjunto de datos por error, se recomienda que proteja los conjuntos de datos críticos frente a una supresión utilizando los parámetros RCLOPTS (DDPROT, DDPRMEM, DSNPROT, DSNPRMEM) o la salida de EQQUXCAT. A continuación se muestra un ejemplo de una sentencia RCLOPTS simple: RCLOPTS DSTDEST(OPC) DSNPRMEM(MYPROT) STEPRESCHK(NO) Capítulo 8. Utilización del almacén de datos 337 Activación del almacén de datos Activación del almacén de datos El JCL de inicio del almacén de datos se puede crear copiando el ejemplo proporcionado, EQQARCH, y personalizándolo para que se adecue a las necesidades de su instalación respecto al convenio de denominación y al número de archivos que se utilizarán. A continuación se muestran las sentencias JCL que son típicas del almacén de datos y que no se aplican a otros componentes de Tivoli Workload Scheduler for z/OS (como el controlador o el comprobador de seguimiento): //OCDST1 JOB CLASS=Y //OCDST1 EXEC PGM=EQQFARCH,REGION=0M,PARM=’EQQDSTP’,TIME=1440 . . . //EQQSDF01 DD DISP=SHR,DSN=OPCDEV.SDF01 //EQQUDF01 DD DISP=SHR,DSN=OPCDEV.UDF01 //EQQUDF02 DD DISP=SHR,DSN=OPCDEV.UDF02 //EQQPKI01 DD DISP=SHR,DSN=OPCDEV.PKI01 //EQQSKI01 DD DISP=SHR,DSN=OPCDEV.SKI01 338 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Capítulo 9. Personalización varia Este capítulo contiene los temas siguientes: v En “Personalización de mensajes de Tivoli Workload Scheduler for z/OS” se describe cómo cambiar el direccionamiento de los mensajes de Tivoli Workload Scheduler for z/OS. v En “Personalización de paneles de Tivoli Workload Scheduler for z/OS” en la página 341 se describe cómo actualizar los paneles de Tivoli Workload Scheduler for z/OS para requisitos específicos de la instalación. v En “Personalización del diseño de la lista de finalizados con error y de la lista de preparados” en la página 341 se describe cómo crear y visualizar sus propios diseños predeterminados. v En “Invocación del soporte de Hiperbatch” en la página 342 se describe cómo los trabajos por lotes controlados por Tivoli Workload Scheduler for z/OS y las tareas iniciadas utilizan Hiperbatch. v En “Personalización del reloj de GMT” en la página 343 se describe cómo Tivoli Workload Scheduler for z/OS actualiza el reloj de GMT. v En “Supervisión de los recursos especiales mediante RODM” en la página 343 se describe cómo puede utilizar el gestor de datos de objetos de recursos (RODM) para supervisar recursos reales utilizados por operaciones de Tivoli Workload Scheduler for z/OS. v En “Creación de módulos de definición de código de caso” en la página 346 se describe cómo crear los módulos que utiliza una recuperación automática de trabajos. v En “Invocación del programa de utilidad de supresión de conjuntos de datos” en la página 346 se describe el programa que puede utilizar para suprimir conjuntos de datos en función de la disposición especificada en el JCL o el estado actual del conjunto de datos en el catálogo. v En “Personalización de Tivoli Workload Scheduler para mensajes en el entorno de capacidades globales con tolerancia a errores” en la página 347 se describe cómo habilitar mensajes para planificación global con capacidades de tolerancia a errores (AWS y EQQPT) de forma que se puedan emitir al MLOG del servidor y a la Consola de salida del sistema. Este capítulo contiene información de diagnóstico, modificación y ajuste. Personalización de mensajes de Tivoli Workload Scheduler for z/OS Todos los mensajes de IBM Tivoli Workload Scheduler for z/OS tienen el prefijo EQQ. Se graban normalmente en el registro de mensajes de Tivoli Workload Scheduler for z/OS o usuario de diálogos de ISPF. Sin embargo, los mensajes se pueden direccionar también a otros destinos. Esto se consigue con los códigos de direccionamiento WTO (write-to-operator). Por ejemplo, se definen dos mensajes de función de comunicación de red (NCF) (EQQV028 y EQQV033) para direccionar como mensajes de información de consola maestra (código de direccionamiento 2). Puede cambiar este direccionamiento en los miembros de mensajes que mantienen los mensajes de NCF. El nombre de miembro de un mensaje determinado es simplemente el número de mensaje menos © Copyright IBM Corp. 1991, 2011 339 Personalización de mensajes el último dígito. Por ejemplo, EQQV028 se encuentra en el miembro EQQV02. Por lo tanto, cada miembro mantiene hasta 10 mensajes. De la misma forma que los mensajes ISPF, los mensajes definidos en la biblioteca de mensajes de Tivoli Workload Scheduler for z/OS constan de dos o más registros. El primer registro mantiene el número de mensaje y las palabras clave. El segundo registro mantiene el texto del mensaje. Una definición de mensaje con la siguiente primera línea indica que el mensaje correspondiente se direccionará al destino representado por el código de direccionamiento 2, además de grabarse en el registro de mensajes: Registro de mensaje no modificado EQQV028 ’ ’ WTO=YES ROUTE=2 Para seleccionar otro destino, por ejemplo, el código de direccionamiento 8, modifique este registro a: Registro de mensaje modificado EQQV028 ’ ’ WTO=YES ROUTE=8 Si desea eliminar todos los destinos a excepción del registro de mensajes, elimine completamente las palabras clave WTO y ROUTE. También puede añadir las palabras clave WTO y ROUTE a los mensajes que aparecen normalmente sólo en el registro de mensajes. Nota: Cuando se emite un mensaje como WTO, el texto del mensaje no puede superar los 70 caracteres. Por este motivo, es posible que sea necesario reorganizar el texto en mensajes modificados para que incluyan WTO=YES. Si la reorganización del texto añade líneas para acomodar todo el mensaje, asegúrese de modificar o añadir la palabra clave LINES en la definición del mensaje. Los mensajes de Tivoli Workload Scheduler for z/OS se almacenan en miembros del conjunto de datos de la biblioteca de mensajes que se crea durante la instalación. Este conjunto de datos contiene mensajes tanto para el registro de mensajes como para el usuario de diálogos de Tivoli Workload Scheduler for z/OS. Las palabras clave WTO y ROUTE no son válidas para mensajes de diálogo, que leen y visualizan las funciones de diálogo de ISPF. No es fácil distinguir entre mensajes de diálogos y mensajes del registro de mensajes ya que utilizan el mismo formato. Si desea añadir las palabras clave WTO o ROUTE al mensaje, la forma más segura es modificar sólo los mensajes que ha visto en el registro de mensajes de Tivoli Workload Scheduler for z/OS. Además, tenga en cuenta que los mensajes grabados en el trabajo por lotes de planificación diaria del conjunto de datos a los que apunta el ddname EQQDIN no se pueden direccionar al registro del sistema cuando se establece la palabra clave WTO=YES. La biblioteca de mensajes es un conjunto de datos particionados normal con registros de longitud fija de 80 bytes. Si desea modificar uno o más mensajes como se ha descrito anteriormente, debe crear una biblioteca de mensajes adicional y copiar en ella los miembros relevantes de la biblioteca de mensajes. A continuación, puede modificar su propia biblioteca y dejar la biblioteca de mensajes en el mismo 340 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Personalización de mensajes estado en que se encontraba cuando se instaló o actualizó mediante el mantenimiento. Posteriormente debe incluir la biblioteca de mensajes en el JCL para la tarea iniciada, concatenada delante de la biblioteca de mensajes en la sentencia EQQMLIB DD. Si crea de esta forma su propia biblioteca de mensajes, debe revisar los cambios que se produzcan en la biblioteca de mensajes como resultado de la actividad de mantenimiento. Consulte la publicación z/OS Routing and Descriptor Codes para obtener más información sobre los códigos de direccionamiento. Personalización de paneles de Tivoli Workload Scheduler for z/OS Si es necesario, puede personalizar los paneles de Tivoli Workload Scheduler for z/OS para añadir información específica de la instalación o para ampliar la ayuda en línea con ejemplos específicos de sus sistemas de aplicación de negocio. La biblioteca de paneles es un conjunto de datos particionados normal con registros de longitud fija de 80 bytes. Si desea modificar uno o más paneles, debe crear una biblioteca de paneles adicional y copiar en ella los miembros correspondientes de la biblioteca de paneles de Tivoli Workload Scheduler for z/OS. A continuación, puede modificar su propia biblioteca y dejar la biblioteca de paneles de Tivoli Workload Scheduler for z/OS en el mismo estado en que se encontraba cuando se instaló o actualizó mediante el mantenimiento. Posteriormente debe incluir la biblioteca de paneles en la concatenación de ISPF delante de la biblioteca de paneles de Tivoli Workload Scheduler for z/OS en la sentencia ISPPLIB DD. Si crea su propia biblioteca de paneles de esta forma, debe revisar los cambios que se produzcan en la biblioteca de paneles de Tivoli Workload Scheduler for z/OS como resultado de la actividad de mantenimiento. Personalización del diseño de la lista de finalizados con error y de la lista de preparados IBM Tivoli Workload Scheduler for z/OS toma el diseño de las listas de finalizados con error y de las listas de preparados de dos fuentes en la secuencia siguiente: v El conjunto de datos de perfil de ISPF (ISPPROF), nombres de miembros EQQELOUT y EQQRLOUT. Estos miembros contienen diseños definidos por el usuario que crea y mantiene cada usuario de forma individual, utilizando el diálogo de Tivoli Workload Scheduler for z/OS. v El conjunto de datos de entrada de tabla ISPF (ISPTLIB), nombres de miembros EQQELDEF y EQQRLDEF. Estos miembros contienen diseños predeterminados definidos por la instalación. Las tablas EQQELDEF y EQQRLDEF de ejemplo se proporcionan con el producto en la biblioteca de tablas ISPF (SEQQTBL0). SEQQTBL0 se asigna en la sentencia ISPTLIB DD durante el procedimiento de instalación. Si desea modificar los diseños predeterminados contenidos en EQQELDEF o EQQRLDEF, realice los pasos siguientes: 1. Utilice el diálogo de Tivoli Workload Scheduler for z/OS para configurar los diseños conforme desea que aparezcan. Esto hará que se grabe una tabla EQQELOUT o EQQRLOUT modificada en el conjunto de datos de perfil de ISPF. Capítulo 9. Personalización varia 341 Personalización de los diseños predeterminados Nota: Edite también todos los diseños predeterminados que desea incluir en la nueva tabla predeterminada. No es necesario que actualice todos los diseños, pero cada uno de ellos que edite se grabará en el conjunto de datos de perfil de ISPF. 2. Copie la tabla modificada de la biblioteca de perfiles de ISPF en la biblioteca de tablas de Tivoli Workload Scheduler for z/OS asignada a ISPTLIB y renómbrela con el nombre de tabla predeterminado (EQQELDEF o EQQRLDEF). Los diseños que ha creado o editado ahora serán los diseños predeterminados para todos los usuarios. Nota: Las tablas EQQLUOUT (xxxxLUOUT con el APAR PQ92255 instalado) y EQQLUDEF se pueden personalizar de la misma forma. Para obtener detalles, consulte el apartado “Configuración de las tablas ISPF” de la publicación IBM Tivoli Workload Scheduler for z/OS Guía de instalación. Invocación del soporte de Hiperbatch Hiperbatch es una mejora del rendimiento de z/OS que funciona con DLF (Data Lookaside Facility) para permitir que los trabajos por lotes y las tareas iniciadas compartan acceso a un conjunto de datos, u objeto de datos. Tivoli Workload Scheduler for z/OS proporciona información de control a DLF relativa a qué operaciones se permite conectarse a qué objetos DLF y qué conjuntos de datos son aptos para Hiperbatch. En Tivoli Workload Scheduler for z/OS, un conjunto de datos apto para Hiperbatch se trata como un recurso especial. Utilizando el diálogo Descripción de recursos especiales, defina un recurso especial con el nombre del conjunto de datos y especifique Y (sí) en el campo Hiperbatch. A continuación, el ejemplo de salida de DLF, EQQDLFX, puede tomar las decisiones siguientes sobre el componente DLF: v ¿Será este conjunto de datos apto para Hiperbatch? v ¿Debe esta operación estar conectada a este objeto de datos? Tivoli Workload Scheduler for z/OS emite colocaciones en cola en el nombre de conjunto de datos y trabajo para notificar a la salida de DLF que el trabajo que se planificará utilizará Hiperbatch. Cuando el trabajo finaliza, Tivoli Workload Scheduler for z/OS comprueba si el mismo conjunto de datos lo necesita una operación inmediatamente sucesiva u otras operaciones preparadas. Si el conjunto de datos no es necesario, Tivoli Workload Scheduler for z/OS inicia el proceso de depuración (es decir, Tivoli Workload Scheduler for z/OS elimina el objeto de datos de Hiperespace) también para operaciones que han finalizado con error, a menos que el valor Mantener en error especifique que se deben mantener los recursos asignados a las operaciones. Sólo el sistema donde se ha iniciado el controlador y los sistemas que participan en el mismo anillo de serialización de recursos global (GRS) interactúan con DLF. Antes de poder utilizar el soporte de Hiperbatch de IBM Tivoli Workload Scheduler for z/OS, debe realizar las tareas siguientes: 1. Instale la salida de conexión/desconexión de DLF. El miembro EQQDLFX de SEQQSAMP contiene un programa ensamblador que proporciona información de control a DLF en función de la información proporcionada por IBM Tivoli Workload Scheduler for z/OS. Consulte la publicación Installation Guide 2. Añada el procedimiento de tarea iniciada EQQPROC. Cuando un objeto en Hiperspace deja de ser requerido por los trabajos, IBM Tivoli Workload 342 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Invocación del soporte de Hiperbatch Scheduler for z/OS inicia una DEPURACIÓN de este objeto. Se emite un mandato de inicio desde dentro de Tivoli Workload Scheduler for z/OS: EQQPROC S EQQPROC, PARM='nombre de recurso' (El JCL de instalación de ejemplo para esta tarea iniciada está contenido en el miembro de ejemplo EQQPROC.) 3. Cree un archivo que contenga JCL de depuración. EQQPROC inicia un programa por lotes de IBM Tivoli Workload Scheduler for z/OS, EQQPURGE. EQQPURGE requiere JCL de entrada para enviar al lector interno de JES. El miembro de ejemplo EQQJCLIN contiene JCL de entrada de ejemplo. Cuando se instala la salida de DLF en un sistema z/OS que no es el controlador de IBM Tivoli Workload Scheduler for z/OS, el JCL debe contener información de direccionamiento para transmitir el trabajo al sistema z/OS correcto. Personalización del reloj de GMT Si cambia la hora local en un rastreador, Tivoli Workload Scheduler for z/OS actualiza el reloj de GMT automáticamente de la forma siguiente: 1. Crea un nuevo registro de reloj y envía un suceso de Tivoli Workload Scheduler al rastreador afectado. 2. El suceso desencadena una renovación del reloj de GMT. 3. El suceso también se reenvía al controlador para su sincronización. Nota: La función de detección automática funciona independientemente de si se cambia la hora local utilizando el mandato set date o set clock o utilizando el temporizador del sysplex. El registro SMF de tipo 90 necesario para la detección automática del cambio de la hora local se crea independientemente de cómo se cambia la hora local. Supervisión de los recursos especiales mediante RODM Puede utilizar el gestor de datos de objetos de recursos (RODM) para realizar un seguimiento del estado real de los recursos utilizados por las operaciones de Tivoli Workload Scheduler for z/OS. RODM es una memoria caché de datos que contiene información sobre recursos reales en la instalación. Productos como por ejemplo AOC/MVS notifican el estado real de los recursos a RODM; RODM refleja el estado actualizando los valores de los campos de las clases o los objetos que representan recursos reales. Los subsistemas en la misma imagen z/OS que RODM se pueden suscribir a campos de RODM. Cuando RODM actualiza un campo, se notifica a todos los subcriptores del campo. El soporte de IBM Tivoli Workload Scheduler for z/OS de RODM permite suscribirse a campos de RODM para campos de los recursos especiales. Cuando RODM notifica un cambio, IBM Tivoli Workload Scheduler for z/OS actualiza los campos de los recursos que tienen una suscripción a éste. Puede suscribirse a RODM para los campos siguientes: DISPONIBLE Campo Disponible del recurso. Este valor sustituye el valor predeterminado y el valor de intervalo. Capítulo 9. Personalización varia 343 Supervisión de los recursos especiales mediante RODM CANTIDAD Campo Cantidad del recurso. Este valor sustituye el valor predeterminado y el valor de intervalo. DEVIATION Campo Desviación. Este campo se utiliza para realizar un ajuste temporal a la cantidad. IBM Tivoli Workload Scheduler for z/OS suma cantidad y desviación conjuntamente para decidir la cantidad de operaciones que puede asignar. Por ejemplo, si la cantidad es 10 y la desviación es -3, las operaciones pueden asignar hasta 7 del recurso. Las palabras clave siguientes se especifican para invocar la supervisión mediante RODM: RODMTASK Se especifica en la sentencia OPCOPTS para el controlador y para cada comprobador de seguimiento que se comunica con un subsistema RODM. RODMPARM Se especifica en la sentencia OPCOPTS para el controlador e identifica el miembro de la biblioteca de parámetros que contiene las sentencias RODMOPTS. RODMOPTS Se especifica para un controlador y contiene la información de destino y suscripción. Es necesaria una sentencia RODMOPTS para cada uno de los campos de cada uno de los recursos que desea supervisar. Cada sentencia se utiliza para suscribirse a un campo en una clase RODM u objeto RODM para un campo en un recurso especial. El valor del campo de RODM se utiliza para establecer el valor del campo de recurso. Las sentencias RODMOPTS se leen cuando se inicia el controlador. Cuando se inicia un comprobador de seguimiento que se comunica con RODM, solicita parámetros al controlador. El controlador envía información de suscripción al comprobador de seguimiento que, a continuación, se suscribe al RODM. Se crea un suceso cuando RODM devuelve un valor, que se utiliza para actualizar el campo del recurso especial en el plan actual. IBM Tivoli Workload Scheduler for z/OS no planifica operaciones que utilizan un recurso especial hasta que RODM ha devuelto el valor del campo actual y IBM Tivoli Workload Scheduler for z/OS ha actualizado el recurso. Para utilizar la supervisión de RODM, debe asegurarse de lo siguiente: v Se inicia un comprobador de seguimiento en la misma imagen de z/OS que la del subsistema RODM al que se envían las solicitudes y se especifica RODMTASK(YES) para el comprobador de seguimiento y el controlador. v Se ha iniciado un grabador de sucesos en el espacio de direcciones de IBM Tivoli Workload Scheduler for z/OS que se comunica con RODM. Este espacio de direcciones crea sucesos de recursos (tipo S) a partir de notificaciones RODM, que IBM Tivoli Workload Scheduler for z/OS utiliza para actualizar el plan actual. v El controlador se conecta al comprobador de seguimiento mediante XCF, NCF o un conjunto de datos de envío/liberación. v Cada espacio de direcciones tiene un identificador de usuario RACF único si se comunica más de 1 espacio de direcciones de IBM Tivoli Workload Scheduler for z/OS con un subsistema RODM, por ejemplo cuando se inician sistemas de producción y de prueba suscritos al mismo subsistema RODM. 344 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Supervisión de los recursos especiales mediante RODM IBM Tivoli Workload Scheduler for z/OS no carga ni mantiene modelos datos en la memoria caché de RODM, ni requiere un modelo de datos específico. No es necesario escribir programas o métodos que utilicen RODM mediante IBM Tivoli Workload Scheduler for z/OS, o definir objetos o campos específicos en RODM. IBM Tivoli Workload Scheduler for z/OS no actualiza los datos definidos por RODM. Los campos de RODM tienen diversos subcampos. El campo de RODM al que se suscribe IBM Tivoli Workload Scheduler for z/OS debe tener un subcampo notificar. Mediante una suscripción a este subcampo, RODM notifica a IBM Tivoli Workload Scheduler for z/OS los cambios del subcampo valor. IBM Tivoli Workload Scheduler for z/OS utiliza los cambios del subcampo valor para supervisar recursos especiales. Pero sólo los tipos de datos siguientes son válidos para el soporte de RODM de IBM Tivoli Workload Scheduler for z/OS: Tabla 38. Tipos de datos RODM válidos para los subcampos de valor Tipo de datos abstracto ID de tipo de datos CharVar (Char) 4 Integer (Bin 31) 10 Smallint (Bin 15) 21 IBM Tivoli Workload Scheduler for z/OS mantiene un estado de RODM para todos los recursos especiales del plan actual. Puede comprobar el estado actual en el diálogo Supervisor de recursos especiales. Cada recurso especial tiene uno de los valores siguientes: N No supervisado. El recurso especial no se supervisa a través de RODM. I Inactivo. La supervisión no está activa actualmente. IBM Tivoli Workload Scheduler for z/OS establece este estado para todas las suscripciones a un subsistema RODM con las que el controlador no puede comunicarse. Esto puede suceder cuando se pierde la comunicación con RODM o con el comprobador de seguimiento. El controlador establece el valor de cada campo supervisado según la palabra clave RODMLOST de RODMOPTS. P Pendiente. IBM Tivoli Workload Scheduler for z/OS ha enviado una solicitud de suscripción a RODM, pero RODM no ha devuelto un valor. A Activo. IBM Tivoli Workload Scheduler for z/OS ha recibido un valor de RODM y el campo del recurso especial se ha actualizado. Notas: 1. Los nombres de clases, objetos y campos de RODM distinguen entre mayúsculas y minúsculas. Asegúrese de preservar el caso al especificar sentencias RODMOPTS en la biblioteca de parámetros. Además, si un nombre no contiene caracteres alfanuméricos o nacionales, debe adjuntar el nombre en comillas. 2. Si IBM Tivoli Workload Scheduler for z/OS se suscribe a RODM para un recurso que no existe en el plan actual y la palabra clave DYNAMICADD de RESOPTS tiene el valor YES o EVENT, el suceso creado desde los datos devueltos por RODM provoca una adición dinámica del recurso. DYNAMICADD se describe en la página 146. 3. Si una solicitud de IBM Tivoli Workload Scheduler for z/OS no se puede procesar inmediatamente porque, por ejemplo, programas de larga ejecución de Capítulo 9. Personalización varia 345 Supervisión de los recursos especiales mediante RODM RODM acceden a los mismos datos a los que IBM Tivoli Workload Scheduler for z/OS necesita acceder, tenga en cuenta los posibles retardos de las horas de inicio de la operación. Creación de módulos de definición de código de caso EQQCASEM es un módulo no ejecutable que mantiene las definiciones de código de caso. Una definición de código de caso es una lista de códigos de terminación anómala y de códigos de retorno que requieren alas mismas acciones de recuperación, y que están agrupados de forma que se pueda hacer referencia a ellos mediante un único nombre. Estas listas las utiliza la función de recuperación automática. Puede crear sus propias definiciones de código de caso ensamblando un archivo que conste de una serie de invocaciones de macro del ensamblador EQQCASEC. Las invocaciones a EQQCASEC deben ser los únicos códigos en el archivo ensamblador. Proporcione al módulo de carga el nombre EQQCASEM cuando edite el enlace y colóquelo en una biblioteca de módulos de carga que esté disponible a Tivoli Workload Scheduler for z/OS. Utilice RMODE(24) y AMODE(24) cuando enlace el módulo. , EQQCASEC CASE=nombre de código,CODES=( código END ) CASE Especifica el código de caso que se definirá cuando se invoque esta macro. Puede tener de 1 a 4 caracteres y debe seguir los estándares de denominación de JCL. CODES Especifica una lista de códigos de terminación de trabajo, códigos de retorno y códigos de caso de IBM Tivoli Workload Scheduler for z/OS. El nombre de código del parámetro CASE representa todos los códigos del parámetro CODES. Cada una de las invocaciones a la macro, con la excepción de la última, define un código de caso. El último registro del módulo debe ser EQQCASEC END. El módulo de carga distribuida define dos códigos de caso, NOAR y SYST. Éstos los crea el siguiente archivo ensamblador: Ejemplo de definición de módulo EQQCASEM EQQCASEC CASE=NOAR,CODES=(S122,S222,CAN,JCLI,JCL,JCCE) EQQCASEC CASE=SYST,CODES=S222 EQQCASEC END Invocación del programa de utilidad de supresión de conjuntos de datos EQQDELDS es un programa proporcionado por IBM Tivoli Workload Scheduler for z/OS que suprime conjuntos de datos en función de la disposición especificada en el JCL y el estado actual en el catálogo. Puede utilizar este programa si desea suprimir conjuntos de datos catalogados por las aplicaciones. 346 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Invocación del programa de utilidad de supresión de conjuntos de datos Se proporciona el JCL para ejecutar EQQDELDS y detalles sobre sus parámetros en el miembro EQQDELDI de la biblioteca SEQQSAMP. Consulte “Supresión de conjuntos de datos en función de la disposición de JCL y del estado del catálogo” en la página 435 para obtener más información. Personalización de Tivoli Workload Scheduler para mensajes en el entorno de capacidades globales con tolerancia a errores Los registros de mensajes EQQPT de Tivoli Workload Scheduler for z/OS y AWS de Tivoli Workload Scheduler no son personalizables, como sucede para los mensajes de Tivoli Workload Scheduler for z/OS (EQQ) de la biblioteca SEQQMSG0. Todos los mensajes AWS y EQQPT se graban normalmente en los siguientes archivos de registro: v Tanto AWS como EQQPT se graban en los archivos de HFS o ZFS TWSMERGE.log, E2EMERGE.log y NETMAN.log. v Tanto los mensajes AWS como EQQPT se direccionan al MLOG del servidor o a la Consola de salida del sistema, o a ambos. Puede personalizar el archivo TWSCCLog.properties ubicado en el directorio de trabajo global con tolerancia a errores en Servicios de sistemas UNIX para especificar qué mensajes se direccionarán al servidor MLOG y al Syslog (para obtener detalles, consulte la publicación Planificación global con capacidades de tolerancia a errores). Los mensajes relativos a problemas de análisis que se encuentran en el archivo TWSCCLog.properties se emiten desde la herramienta CCLOG del archivo stderr y de los archivos <date> del directorio stdlist. Capítulo 9. Personalización varia 347 Personalización de mensajes globales con tolerancia a errores 348 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Parte 2. Integridad de datos Capítulo 10. Copia de seguridad y recuperación de conjuntos de datos. . . . . . . . . . Procedimientos de copia de seguridad . . . . . Cómo gestiona Tivoli Workload Scheduler for z/OS la recuperación del plan actual . . . . . Principios de recuperación del plan actual . . . Proceso de recuperación del plan actual . . . Proceso del plan actual durante el inicio de Tivoli Workload Scheduler for z/OS. . . . . Inicio de Tivoli Workload Scheduler for z/OS con un conjunto de datos de punto de comprobación vacío . . . . . . . . . Inicio de Tivoli Workload Scheduler for z/OS con un conjunto de datos de punto de comprobación válido . . . . . . . . . Cómo evitar que la copia de seguridad del plan actual resulte dañada . . . . . . . . . . Restauración de un archivo dañado de Tivoli Workload Scheduler for z/OS a partir de la copia de seguridad . . . . . . . . . . . . . Restauración del conjunto de datos de descripción de la estación de trabajo (WS) . . . Restauración del conjunto de datos de descripción de la aplicación (AD). . . . . . Restauración del conjunto de datos de instrucción del operador (OI) . . . . . . . Restauración del conjunto de datos de descripción de recurso especial (RD). . . . . Restauración del conjunto de datos de información complementaria (SI) . . . . . . Restauración del conjunto de datos del plan a largo plazo (LPT) . . . . . . . . . . . Restauración del conjunto de datos de repositorio de JCL (JS) . . . . . . . . . Cómo volver a crear el plan actual a partir del plan a largo plazo . . . . . . . . . . . . . Cómo volver a crear el plan actual a partir del nuevo plan actual y del registro de archivado de JT Recuperación de errores en el registro de seguimiento de trabajos . . . . . . . . . . Problemas del conjunto de datos de registro dual de JT . . . . . . . . . . . . . . . . Recuperación de errores en el registro de archivado de JT . . . . . . . . . . . . . . . . Recuperación de errores en el conjunto de datos de punto de comprobación . . . . . . . . . . Recuperación de errores en los conjuntos de datos de suceso. . . . . . . . . . . . . . . Recuperación de errores en un conjunto de datos de envío/liberación . . . . . . . . . . . Recuperación de errores en el conjunto de datos de ampliación del plan actual . . . . . . . . . Recuperación automática de anomalías del controlador . . . . . . . . . . . . . . Notificación de anomalías del controlador . . . © Copyright IBM Corp. 1991, 2011 Cómo volver a crear el archivo Symphony a partir del plan actual . . . . . . . . . 351 351 Capítulo 11. Limpieza y recuperación de conjuntos de datos del almacén de datos . . . Supresión de datos de la base de datos . . . . . Exportación de datos a un archivo de copia de seguridad . . . . . . . . . . . . . . Importación de datos desde un archivo de copia de seguridad . . . . . . . . . . . . . . Recuperación de anomalía . . . . . . . . . Qué hacer cuando se llenan los archivos de datos Subtarea de limpieza . . . . . . . . . . . 352 353 354 356 356 357 357 358 358 359 359 359 360 360 361 361 362 363 . 367 | | Capítulo 12. Planificación de recuperación tras desastre. . . . . . . . . . . . . . . Diseño de la DRP de Tivoli Workload Scheduler for z/OS . . . . . . . . . . . . . . . . Opciones del centro secundario . . . . . . Estandarización del entorno . . . . . . . Convenios de denominación . . . . . . Requisitos de la biblioteca . . . . . . . Variaciones de capacidad y carga de trabajo Consideraciones de JCL . . . . . . . . Automatización en el centro secundario . . Implementación de la DRP de Tivoli Workload Scheduler for z/OS . . . . . . . . . . . Recuperación a proceso de inicio del día . . . Requisitos de copia de seguridad . . . . . Proceso de recuperación . . . . . . . . Recuperación a un punto de recuperación predefinido . . . . . . . . . . . . . Requisitos de copia de seguridad . . . . . Proceso de recuperación . . . . . . . . Recuperación a punto de anomalía . . . . . Requisitos de copia de seguridad . . . . . Proceso de recuperación . . . . . . . . Consideraciones sobre pruebas de recuperación tras desastre en un entorno global . . . . . . 369 369 370 371 371 371 372 373 373 373 374 374 374 374 375 375 376 376 376 378 379 379 381 382 382 384 385 363 363 364 365 365 366 366 367 349 350 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Capítulo 10. Copia de seguridad y recuperación de conjuntos de datos IBM Tivoli Workload Scheduler for z/OS es, en cierto sentido, un sistema en línea que crea y gestiona dos recursos, el plan a largo plazo (LPT) y el plan actual (CP). Estos dos recursos y los conjuntos de datos necesarios para volver a crearlos son activos importantes que debe proteger frente a daños. Para ello, debe establecer procedimientos de copia de seguridad de conjuntos de datos para permitir que el administrador de IBM Tivoli Workload Scheduler for z/OS recupere estos recursos si se pierden o dañan. La tarea de enviar y realizar un seguimiento del proceso por lotes es necesariamente compleja e implica una serie de conjuntos de datos. Por esta razón, IBM Tivoli Workload Scheduler for z/OS maneja automáticamente la copia de seguridad y sincronización de los planes actuales. Este proceso se describe detalladamente en la publicación Managing the Workload Los procedimientos de recuperación pueden incluir el uso de los recursosespera dinámica de IBM Tivoli Workload Scheduler for z/OS. Si el sistema z/OS en el que reside el controlador falla o el propio controlador falla, la función del controlador de IBM Tivoli Workload Scheduler for z/OS se puede transferir a un sistema z/OS en espera. Para utilizar este recurso, los sistemas deben estar en ejecución en un sysplex z/OS utilizando el recurso de acoplamiento entre sistemas (XCF). Procedimientos de copia de seguridad Se debe realizar periódicamente copia de seguridad de los siguientes conjuntos de datos de VSAM: v Conjunto de datos de descripción de la aplicación (AD) v Conjunto de datos de descripción de la estación de trabajo (WS) v Conjunto de datos de instrucción del operador (OI) v Conjunto de datos de descripción de recurso especial (RD) v Conjunto de datos de información complementaria (SI) (en caso de actividad alta) v Conjunto de datos de LTP No es necesario realizar diariamente copia de seguridad del conjunto de datos del repositorio de JCL (JS) con fines de recuperación. IBM Tivoli Workload Scheduler for z/OS realiza automáticamente copia de seguridad del archivo JS en función del valor especificado para la palabra clave MAXJSFILE de la sentencia JTOPTS para el subsistema. Sin embargo, puede inhabilitar esta copia de seguridad automática y planificar copias de seguridad del archivo JS como operaciones de trabajos utilizando el mandato BACKUP; por ejemplo, si desea planificar copias de seguridad a horas durante las que la carga de trabajo del sistema es baja. El conjunto de datos JS consta de dos conjuntos de datos, uno activo y el otro inactivo. La recuperación consiste simplemente en copiar el conjunto de datos inactivo en el conjunto de datos activo. Puede realizar copia de seguridad de los conjuntos de datos de VSAM utilizando la función REPRO del programa de utilidad IDCAMS. Pero no puede utilizar REPRO si la copia de seguridad es un archivo secuencial y la longitud de registro es superior a 32.760. En su lugar, utilice DFSMSdss, o un producto equivalente, © Copyright IBM Corp. 1991, 2011 351 Procedimientos de copia de seguridad para realizar la copia de seguridad. Si utiliza DFSMS, considere DFSMShsm ABARS para la copia de seguridad y restauración de datos. ABARS simplifica el proceso de copia de seguridad y recuperación. Normalmente, los conjuntos de datos de VSAM se descargan en un conjunto de datos secuencial. Una práctica recomendada es utilizar un grupo de datos de generación como conjunto de datos de copia de seguridad. Si los conjuntos de datos de copia de seguridad están ubicados en DASD, éstos deben estar en un volumen distinto del conjunto de datos VSAM del que se está realizando copia de seguridad. En un dispositivo de almacenamiento de acceso directo 3380, el conjunto de datos de copia de seguridad debe estar en un conjunto de disco de cabezal distinto que el conjunto de datos del que se está realizando copia de seguridad. Nota: Los conjuntos de datos no VSAM, como por ejemplo el conjunto de datos de biblioteca de trabajos, el conjunto de datos de biblioteca de procedimientos y el conjunto de datos de biblioteca de mensajes JCC, no los utiliza nunca IBM Tivoli Workload Scheduler for z/OS. Por lo tanto, estos conjuntos de datos no se consideran recursos propiedad de IBM Tivoli Workload Scheduler for z/OS. Utilice los procedimientos habituales de copia de seguridad y recuperación para estos conjuntos de datos. El conjunto de datos de plan a largo plazo proporciona principalmente entrada para los trabajos por lotes del plan diario que crean un nuevo plan actual. Algunos de los trabajos por lotes del plan diario actualizan el conjunto de datos del plan a largo plazo para establecer el estado de las apariciones en el plan a largo plazo. El plan a largo plazo y los planes actuales se deben sincronizar; de lo contrario, el proceso del plan diario fallará. IBM Tivoli Workload Scheduler for z/OS crea una copia de seguridad del plan a largo plazo cuando se ejecutan el plan a largo plazo y trabajos por lotes de planificación diaria. La copia de seguridad se graba en un archivo de VSAM con el ddname EQQLTBKP. Antes y después de generar el nuevo plan a largo plazo, se realiza una copia de seguridad de los trabajos por lotes a largo plazo. Esto asegura que un plan a largo plazo utilizable esté disponible en el archivo de copia de seguridad con el ddname EQQLTBKP después de una ejecución por lotes del plan a largo plazo. Para trabajos por lotes de proceso de datos, se realiza copia de seguridad a largo plazo después de que se haya creado satisfactoriamente el nuevo plan actual. Esto asegura que existe una copia de seguridad del plan a largo plazo sincronizada con el nuevo plan actual generado en el archivo con el ddname EQQNCPDS. Cómo gestiona Tivoli Workload Scheduler for z/OS la recuperación del plan actual El planificador automáticamente realiza copia de seguridad del plan actual. En función de la carga de trabajo, es posible que el plan actual se actualice muchas veces por segundo. Por esta razón, y debido a que el plan actual es un recurso crítico, el planificador lo maneja de forma distinta a las demás bases de datos y conjuntos de datos. Con la introducción de estaciones de trabajo tolerantes a errores, se puede generar un nuevo archivo, denominado Symphony, durante las ejecuciones de trabajos por lotes del plan diario. La recuperación del plan actual de una situación de error puede implicar también la recuperación del archivo 352 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Gestión de la recuperación del plan actual Symphony. Para obtener más información sobre el proceso de copia de seguridad del plan actual y el archivo Symphony, consulte la publicación Managing the Workload. Principios de recuperación del plan actual Tivoli Workload Scheduler for z/OS está diseñado de forma que en la mayoría de situaciones de error, el plan actual se puede recuperar automáticamente sin que sea necesaria ninguna acción por parte del usuario. Para conseguir EQQCP1DS EQQCP2DS EQQSCPDS EQQCXDS EQQNCPDS EQQNCXDS EQQJTnn EQQDLnn EQQJTARC EQQCKPT la recuperación, se utilizan los siguientes datos: Conjunto de datos del plan actual primario Conjunto de datos del plan actual alternativo Copia del plan actual utilizada para generar el archivo Symphony. Conjunto de datos de ampliación del plan actual Conjunto de datos del nuevo plan actual Conjunto de datos de ampliación del nuevo plan actual Registros de seguimiento de trabajos inactivos y actuales Registros de seguimiento de trabajos duales inactivos y actuales Registro de archivado de seguimiento de trabajos Conjunto de datos de punto de comprobación. Sin embargo, las descripciones que se muestran a continuación utilizan estos términos lógicos para describir el CP y sus conjuntos de datos asociados: Plan actual Se utiliza cuando se describe el plan actual en general. El plan actual consta de un conjunto de datos del plan actual activo y de un archivo de ampliación (CX). Plan actual activo Hace referencia al conjunto de datos del plan actual que se utiliza actualmente en Tivoli Workload Scheduler for z/OS. Es EQQCP1DS o EQQCP2DS. Cada vez que se realiza una copia de seguridad del plan actual, Tivoli Workload Scheduler for z/OS cambia el plan actual activo al otro conjunto de datos. Managing the Workload describe el proceso de copia de seguridad del plan actual. Ampliación del plan actual Hace referencia al archivo que contiene la información de recursos especiales. El archivo de ampliación se mantiene en un espacio de datos, respaldado por el archivo de DASD EQQCXDS. Cuando se realiza copia de seguridad del plan actual, el espacio de datos se renueva en el archivo de DASD. Plan actual inactivo Hace referencia al conjunto de datos del plan actual que no se utiliza actualmente. Contiene una copia de seguridad del plan actual. Es EQQCP1DS o EQQCP2DS. Nuevo plan actual Hace referencia a una nueva versión del plan actual, que crea uno de los trabajos por lotes de planificación diaria. Hace referencia al conjunto de datos EQQNCPDS y al conjunto de datos EQQNCXDS. Registro de seguimiento de trabajos actuales e inactivos Hace referencia a los conjuntos de datos utilizados por IBM Tivoli Workload Scheduler for z/OS para registrar las actualizaciones del plan actual y registrar la información de auditoría para los archivos solicitados. Capítulo 10. Copia de seguridad y recuperación de conjuntos de datos 353 Gestión de la recuperación del plan actual Debe utilizar como mínimo dos registros de seguimiento de trabajos, a los que hacen referencia los ddnames EQQJT01 y EQQJT02. Puede utilizar hasta 99 registros de seguimiento de trabajos. Los registros de JT se utilizan de forma cíclica, y IBM Tivoli Workload Scheduler for z/OS automáticamente cambia al siguiente JT disponible después de una copia de seguridad de CP. Los datos del conjunto de datos inactivo se copian en el registro de archivado y el conjunto de datos se vacía en preparación para una futura utilización. Debe utilizar como mínimo 5 registros de seguimiento de trabajos. Éste es el número predeterminado en la palabra clave JTLOGS de JTOPTS. Registro de seguimiento de trabajos duales actuales e inactivos Si se solicita la función de registro dual, IBM Tivoli Workload Scheduler for z/OS duplica los registros de JT en el registro de JT dual correspondiente. Los registros duales se cambian simultáneamente, y en la misma secuencia, que los registros de JT. De esta forma, el número de conjuntos de datos de seguimiento dual de trabajos está determinado por el número de conjuntos de datos de seguimiento normal de trabajos. Registro de archivado de seguimiento de trabajos Representa los datos de seguimiento de trabajos acumulados desde que se creó el nuevo plan actual. Cuando se cambia el registro de JT, los datos del conjunto de datos inactivos se añaden al registro de archivado. El registro de archivado se copia en el conjunto de datos al que hace referencia el ddname EQQTROUT durante el proceso de planificación diario. Cuando IBM Tivoli Workload Scheduler for z/OS toma el control del nuevo plan de trabajo actual, el conjunto de datos de archivado se vacía. Punto de comprobación Hace referencia al conjunto de datos EQQCKPT, que contiene información sobre el estado actual del sistema IBM Tivoli Workload Scheduler for z/OS, e incluye qué conjuntos de datos de seguimiento de trabajos y plan actual están actualmente activos. Archivo Symphony Representa un plan local para un conjunto de estaciones de trabajo tolerantes a errores y se actualiza según los cambios del plan actual y local. El principio básico de la recuperación del plan actual de IBM Tivoli Workload Scheduler for z/OS es que si el plan actual activo pasa a estar inutilizable por cualquier motivo, IBM Tivoli Workload Scheduler for z/OS debe siempre poder volver a crear un plan actual actualizado a partir del plan actual de copia de seguridad y los diversos registros de seguimiento de trabajos. La forma en la que IBM Tivoli Workload Scheduler for z/OS realmente realiza esta tarea se describe en “Proceso de recuperación del plan actual”. Proceso de recuperación del plan actual Cuando IBM Tivoli Workload Scheduler for z/OS sospecha que el plan actual activo está inutilizable, automáticamente realiza el proceso de recuperación. IBM Tivoli Workload Scheduler for z/OS utiliza el conjunto de datos del plan actual alternativo o del nuevo plan actual (EQQNCPDS) y el registro de seguimiento de trabajos activos para crear un plan actual que esté completamente actualizado. Aquí se proporciona una descripción paso a paso del proceso de recuperación del plan actual: 1. El plan actual se bloquea para impedir actualizaciones por parte de los sucesos de seguimiento de trabajos y los usuarios de los diálogos. 2. El plan actual activo se borra. 354 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Gestión de la recuperación del plan actual 3. El plan actual alternativo o el nuevo plan actual se copian en el plan actual activo. Los indicadores en el conjunto de datos de punto de comprobación determinan cuál de los dos realmente se utiliza. Esto se explica más detalladamente en “Proceso del plan actual durante el inicio de Tivoli Workload Scheduler for z/OS” en la página 356. 4. La identidad del registro de seguimiento de trabajos activos se obtiene del registro de punto de comprobación. Se utiliza cada uno de los registros del registro de JT actual para actualizar el plan actual activo. Si la recuperación se realiza a partir del plan actual, se utilizan el registro de JT actual y el registro de archivado de JT para volver a aplicar los sucesos que se han producido desde la creación del nuevo plan actual. 5. El plan actual activo ahora está actualizado. Se realiza una copia de seguridad del plan actual. 6. Se inicia o continúa el proceso normal de IBM Tivoli Workload Scheduler for z/OS. Si planifica la característica global con capacidades de tolerancia a errores, realice las siguientes acciones manuales para asegurarse de que el archivo Symphony esté alineado con el plan actual que se ha vuelto a crear: 1. Desde el diálogo OPC, seleccione la opción 3, PLANIFICACIÓN DIARIA. Se visualiza el diálogo Producción de planes diarios de OPC. 2. A continuación, seleccione la opción 5, RENOVACIÓN DE SYMPHONY. 3. Envíe el trabajo por lotes de renovación de Symphony para crear un archivo Symphony alineado con el plan actual. La recuperación del plan actual se realiza para las situaciones siguientes: v Durante el inicio de IBM Tivoli Workload Scheduler for z/OS, si los planes actuales (CP1 y CP2) no son iguales. v Durante el inicio de IBM Tivoli Workload Scheduler for z/OS, si se ha especificado CURRPLAN(NEW) en la sentencia JTOPTS. v Durante el proceso normal de IBM Tivoli Workload Scheduler for z/OS, si el plan actual activo resulta dañado o no está accesible. Si el archivo CX del espacio de datos pasa a estar inutilizable, IBM Tivoli Workload Scheduler for z/OS realiza las siguientes acciones de recuperación: 1. El plan actual se bloquea para impedir actualizaciones por parte de los sucesos de seguimiento de trabajos y los usuarios de los diálogos. 2. Se suprime el espacio de datos CX. 3. El archivo de DASD CX se copia en un nuevo espacio de datos 4. La identidad del registro de seguimiento de trabajos activos se obtiene del registro de punto de comprobación. Los registros del registro de JT actual se utilizan para actualizar el espacio de datos. 5. El archivo del espacio de datos ahora está actualizado. Se realiza una copia de seguridad del plan actual. 6. Se inicia o continúa el proceso normal de IBM Tivoli Workload Scheduler for z/OS. Cuando IBM Tivoli Workload Scheduler for z/OS realiza recuperación del nuevo plan actual, el archivo EQQNCXDS se copia en EQQCXDS, se crea un espacio de datos y se vuelven a aplicar sucesos utilizando el registro de archivado de JT y el registro de JT actual. El espacio de datos se renueva en el archivo de DASD durante la copia de seguridad del plan actual subsiguiente. Capítulo 10. Copia de seguridad y recuperación de conjuntos de datos 355 Gestión de la recuperación del plan actual Si el archivo CX de DASD pasa a estar inutilizable, siga las instrucciones en “Recuperación de errores en el conjunto de datos de ampliación del plan actual” en la página 366. Proceso del plan actual durante el inicio de Tivoli Workload Scheduler for z/OS En esta sección se describen las dos condiciones de proceso del plan actual que se pueden producir cuando: v Se inicia IBM Tivoli Workload Scheduler for z/OS con un conjunto de datos de punto de comprobación vacío v Se inicia IBM Tivoli Workload Scheduler for z/OS con un conjunto de datos de punto de comprobación válido. Inicio de Tivoli Workload Scheduler for z/OS con un conjunto de datos de punto de comprobación vacío El conjunto de datos de punto de comprobación está vacío la primera vez que se inicia IBM Tivoli Workload Scheduler for z/OS. También está vacío si se ha suprimido y reasignado por alguna razón, como por ejemplo si se ha dañado. Cuando IBM Tivoli Workload Scheduler for z/OS se inicia por primera vez, se produce lo siguiente: 1. El conjunto de datos de punto de comprobación se formatea y se graban en él los valores iniciales. 2. Cuando se especifica JTOPTS CURRPLAN(CURRENT), IBM Tivoli Workload Scheduler for z/OS emitirá el mensaje EQQN026W SE HA RECHAZADO UN NUEVO PLAN ACTUAL (NCP) y se detendrá el proceso. 3. Cuando se especifica JTOPTS CURRPLAN(NEW), IBM Tivoli Workload Scheduler for z/OS realiza un proceso de recuperación utilizando el nuevo plan actual (EQQNCPDS y EQQNCXDS), tal y como se describe en “Proceso de recuperación del plan actual” en la página 354. Es posible que haya un nuevo plan actual si migra desde un release o versión anterior y ha colocado el plan actual convertido en los conjuntos de datos del nuevo plan actual como parte del procedimiento de migración. Si el nuevo plan actual está vacío, el proceso de recuperación finaliza, IBM Tivoli Workload Scheduler for z/OS pasa a estar activo sin un plan actual y el seguimiento de trabajos no se inicia. 4. Si el proceso de recuperación con el nuevo plan actual es satisfactorio, IBM Tivoli Workload Scheduler for z/OS inicia el proceso normal. Si planifica la característica global con capacidades de tolerancia a errores, realice las siguientes acciones manuales para asegurarse de que el archivo Symphony esté alineado con el plan actual que se ha vuelto a crear: 1. Desde el diálogo OPC, seleccione la opción 3, PLANIFICACIÓN DIARIA. Se visualiza el diálogo Producción de planes diarios de OPC. 2. A continuación, seleccione la opción 5, RENOVACIÓN DE SYMPHONY. 3. Envíe el trabajo por lotes de renovación de Symphony para crear un archivo Symphony alineado con el plan actual. 356 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Gestión de la recuperación del plan actual Si inicia IBM Tivoli Workload Scheduler for z/OS después de haber suprimido y reasignado el conjunto de datos de punto de comprobación, y ha especificado JTOPTS CURRPLAN(NEW), se producen las acciones siguientes: 1. IBM Tivoli Workload Scheduler for z/OS realiza un proceso de recuperación con el nuevo plan actual tal y como se describe en “Proceso de recuperación del plan actual” en la página 354. 2. Se inicia el proceso normal de IBM Tivoli Workload Scheduler for z/OS. Nota: Cuando el proceso de recuperación del plan actual se realiza después de que se haya iniciado IBM Tivoli Workload Scheduler for z/OS con un conjunto de datos de punto de comprobación vacío, IBM Tivoli Workload Scheduler for z/OS utiliza los conjuntos de datos primarios EQQJT01, EQQDL01 y EQQJS1DS como conjuntos de datos activos. Si un conjunto de datos primario no era el conjunto de datos activo en la última conclusión, copie los datos del conjunto de datos activo anteriormente en el conjunto de datos primario. Si no lo hace, los sucesos desde la última copia de seguridad del plan actual no se aplicarán. Puede comprobar los conjuntos de datos que estaban activos revisando el registro de mensajes o buscando los conjuntos de datos con la indicación de fecha y hora más reciente. Inicio de Tivoli Workload Scheduler for z/OS con un conjunto de datos de punto de comprobación válido Debe existir un conjunto de datos de punto de comprobación válido incluso si IBM Tivoli Workload Scheduler for z/OS ha finalizado de forma anómala la vez anterior. Cuando se inicia IBM Tivoli Workload Scheduler for z/OS, éste lee el conjunto de datos de punto de comprobación para determinar cuál es el plan actual y el registro de seguimiento de trabajos activos. Se abre el registro de seguimiento de trabajos. Si no se encuentra ningún registro de seguimiento de trabajos, esto indica que IBM Tivoli Workload Scheduler for z/OS ha finalizado normalmente ya que se realiza un conmutación de registros JT cuando la copia de seguridad de CP se completa en una terminación normal. Si hay registros en el registro de seguimiento de trabajos después de la posición de la copia de seguridad, esto indica que IBM Tivoli Workload Scheduler for z/OS no ha finalizado normalmente. En este caso, se realiza el proceso de recuperación utilizando el plan actual de copia de seguridad y el conjunto de datos de CX tal y como se describe en “Proceso de recuperación del plan actual” en la página 354. A continuación, se inicia el proceso normal de IBM Tivoli Workload Scheduler for z/OS. Si el archivo Symphony no está actualizado con el plan actual, seleccione la opción 5 del panel Producción de planes diarios de OPC o envíe el trabajo por lotes del plan diario. Cómo evitar que la copia de seguridad del plan actual resulte dañada Si se produce un error en el plan actual mientras IBM Tivoli Workload Scheduler for z/OS está en ejecución y IBM Tivoli Workload Scheduler for z/OS no lo detecta, se recomienda encarecidamente que cancele el espacio de direcciones del controlador en lugar de detenerlo como se realiza normalmente. Esto impide que se copie un error lógico del plan actual activo en el conjunto de datos del plan actual alternativo durante el proceso de copia de seguridad. Cuando se reinicie Capítulo 10. Copia de seguridad y recuperación de conjuntos de datos 357 Gestión de la recuperación del plan actual IBM Tivoli Workload Scheduler for z/OS, el plan actual activo se volverá a crear a partir del plan actual alternativo. Esto eliminará cualquier error del plan actual activo. Si IBM Tivoli Workload Scheduler for z/OS reconoce que el plan actual activo está dañado o que ha dejado de estar accesible, se realiza automáticamente una recuperación del plan actual activo. Esto se describe en “Proceso de recuperación del plan actual” en la página 354. Restauración de un archivo dañado de Tivoli Workload Scheduler for z/OS a partir de la copia de seguridad Para que IBM Tivoli Workload Scheduler for z/OS funcione con normalidad, los conjuntos de datos de VSAM que utiliza IBM Tivoli Workload Scheduler for z/OS no deben contener errores. Si un conjunto de datos VSAM ha resultado dañado, se debe restaurar a partir de una copia de seguridad. Cuando se vuelve a crear un conjunto de datos VSAM a partir de una copia de seguridad, debe asignar un nuevo conjunto de datos. Pero conserve el conjunto de datos dañado para la determinación de problemas una vez que se haya reanudado el servicio normal de IBM Tivoli Workload Scheduler for z/OS. Debe renombrar el archivo dañado de forma que pueda utilizar el mismo nombre para el nuevo conjunto de datos o bien asignar al conjunto de datos un nuevo nombre. Si asigna al conjunto de datos un nuevo nombre, también debe cambiar el procedimiento de JCL de IBM Tivoli Workload Scheduler for z/OS y todos los trabajos por lotes que hacen referencia al conjunto de datos dañado. Puede actualizar los trabajos por lotes editando los miembros afectados en la biblioteca del esqueleto de trabajos de ISPF. El procedimiento de restauración varía levemente, en función del conjunto de datos que esté dañado. Estas diferencias se explican en las secciones siguientes. Todos los procedimientos de restauración asumen que existe una copia de seguridad utilizable disponible. Nota: Si restaura un archivo de base de datos, AD, WS, OI, RD o SI, IBM Tivoli Workload Scheduler for z/OS no puede recuperar actualizaciones realizadas desde la última copia de seguridad. Debe considerar la utilización de la sentencia AUDIT para registrar los accesos a estos archivos de forma que tenga un registro de las actualizaciones que necesita volver a aplicar. También puede intentar acceder al archivo antes de detener IBM Tivoli Workload Scheduler for z/OS y ordenar la lista de elementos en el momento de la última actualización en orden descendente. Tenga en cuenta los elementos que han cambiado desde que se creó la última copia de seguridad. Restauración del conjunto de datos de descripción de la estación de trabajo (WS) Para restaurar el conjunto de datos de WS: 1. Detenga IBM Tivoli Workload Scheduler for z/OS. 2. Asigne un nuevo conjunto de datos de WS. 3. Copie el conjunto de datos de copia de seguridad en el conjunto de datos de WS. 358 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Restauración de un archivo dañado a partir de la copia de seguridad 4. Si ha asignado al conjunto de datos un nuevo nombre, actualice todos los JCL (ddname EQQWSDS) para que hagan referencia al nuevo conjunto de datos de WS. 5. Inicie IBM Tivoli Workload Scheduler for z/OS. 6. Entre en el diálogo Calendario para verificar que el calendario esté actualizado. Vuelva a aplicar los cambios realizados desde la última copia de seguridad del archivo de WS. 7. Entre en el diálogo Descripción de la estación de trabajo para verificar que las estaciones de trabajo están correctamente definidas y que las definiciones de intervalo de tiempo abierto están actualizadas. Vuelva a aplicar los cambios realizados desde la última copia de seguridad del archivo de WS. Restauración del conjunto de datos de descripción de la aplicación (AD) Para restaurar el conjunto de datos de AD: 1. Detenga IBM Tivoli Workload Scheduler for z/OS. 2. Asigne un nuevo conjunto de datos de AD. 3. Copie el conjunto de datos de copia de seguridad en el conjunto de datos de AD. 4. Si ha asignado al conjunto de datos un nuevo nombre, actualice todos los JCL (ddname EQQADDS) para que hagan referencia al nuevo conjunto de datos de AD. 5. Inicie IBM Tivoli Workload Scheduler for z/OS. 6. Entre en el diálogo Descripción de la aplicación para verificar que las aplicaciones se han definido correctamente. Vuelva a aplicar todos los cambios desde la creación de la copia de seguridad de AD. Restauración del conjunto de datos de instrucción del operador (OI) Para restaurar el conjunto de datos de OI: 1. Detenga IBM Tivoli Workload Scheduler for z/OS. 2. Asigne un nuevo conjunto de datos de OI. 3. Copie el conjunto de datos de copia de seguridad en el conjunto de datos de OI. 4. Si ha asignado al conjunto de datos un nuevo nombre, actualice todos los JCL (ddname EQQOIDS) para que hagan referencia al nuevo conjunto de datos de OI. 5. Inicie IBM Tivoli Workload Scheduler for z/OS. 6. Entre en el diálogo Instrucción del operador para verificar que las instrucciones se han definido correctamente. Todas las instrucciones añadidas desde la creación de la copia de seguridad de OI se deben añadir de nuevo. Restauración del conjunto de datos de descripción de recurso especial (RD) Para restaurar el conjunto de datos de RD: 1. Detenga IBM Tivoli Workload Scheduler for z/OS. 2. Asigne un nuevo conjunto de datos de RD. 3. Copie el conjunto de datos de copia de seguridad en el conjunto de datos de RD. Capítulo 10. Copia de seguridad y recuperación de conjuntos de datos 359 Restauración de un archivo dañado a partir de la copia de seguridad 4. Si ha asignado al conjunto de datos un nuevo nombre, actualice todos los JCL (ddname EQQRDDS) para que hagan referencia al nuevo conjunto de datos de RD. 5. Inicie IBM Tivoli Workload Scheduler for z/OS. 6. Entre en el diálogo Descripciones de recursos especiales para verificar que los recursos se han definido correctamente. Vuelva a aplicar todos los cambios realizados desde la creación de la última copia de seguridad de RD. Restauración del conjunto de datos de información complementaria (SI) Para restaurar el conjunto de datos de SI: 1. Detenga IBM Tivoli Workload Scheduler for z/OS. 2. Asigne un nuevo conjunto de datos de SI. 3. Copie el conjunto de datos de copia de seguridad al conjunto de datos de SI. 4. Si ha asignado al conjunto de datos un nuevo nombre, actualice todos los JCL (ddname EQQSIDS) para que hagan referencia al nuevo conjunto de datos de SI. 5. Inicie IBM Tivoli Workload Scheduler for z/OS. 6. Especifique el diálogo ETT y verifique que los criterios de ETT se han definido correctamente. Vuelva a aplicar todos los cambios desde la creación de la copia de seguridad de SI. Restauración del conjunto de datos del plan a largo plazo (LPT) La forma de restaurar el conjunto de datos de LTP depende de cuándo se creó el conjunto de datos de copia de seguridad. Existe una estrecha conexión entre el plan actual y el conjunto de datos de LTP. Si es posible, se debe restaurar el LTP a partir de una copia de seguridad creada después de la última vez que IBM Tivoli Workload Scheduler for z/OS tomó el control de un nuevo plan actual creado por un trabajo por lotes del plan diario. Si existe una copia de seguridad de LTP de este tipo, utilícela para restaurar el conjunto de datos de LTP: 1. Detenga IBM Tivoli Workload Scheduler for z/OS. 2. Asigne un nuevo conjunto de datos de LTP. 3. Copie el conjunto de datos de copia de seguridad en el conjunto de datos de LTP. Utilice el conjunto de datos con ddname EQQLTBKP. 4. Si ha asignado al conjunto de datos un nuevo nombre, actualice todos los JCL (ddname EQQLTDS) para que hagan referencia al nuevo conjunto de datos de LTP. 5. Inicie IBM Tivoli Workload Scheduler for z/OS. 6. Entre en el diálogo Plan a largo plazo para verificar que las apariciones se han definido correctamente. Todas las apariciones añadidas desde la creación de la copia de seguridad de LTP se deben añadir de nuevo. Si la copia de seguridad de LTP que coincide con el plan actual está inutilizable, debe restaurar el LTP tal y como se ha descrito anteriormente y crear un nuevo plan actual a partir del LTP restaurado. 360 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Restauración de un archivo dañado a partir de la copia de seguridad Restauración del conjunto de datos de repositorio de JCL (JS) El conjunto de datos de JS consta de dos conjuntos de datos, uno activo y el otro inactivo. Si existe un error en el conjunto de datos activo, puede copiar el conjunto de datos inactivo en el conjunto de datos activo para la recuperación. Lleve a cabo el procedimiento siguiente: 1. Si IBM Tivoli Workload Scheduler for z/OS está activo, deténgalo. 2. Asigne un nuevo conjunto de datos. 3. Copie el conjunto de datos inactivo en el nuevo conjunto de datos de JS. 4. Si ha asignado al conjunto de datos un nuevo nombre, actualice todos los JCL (EQQJSnDS) para que hagan referencia al nuevo conjunto de datos. 5. Revise el registro de mensajes de IBM Tivoli Workload Scheduler for z/OS para determinar cuándo el conjunto de datos de JS dañado se utilizó por primera vez. 6. Inicie IBM Tivoli Workload Scheduler for z/OS. 7. Vuelva a realizar todos los cambios del JCL de IBM Tivoli Workload Scheduler for z/OS que se realizaron desde que se utilizó por primera vez el conjunto de datos de JS dañado y que se aplica a operaciones que no se han iniciado aún. Cómo volver a crear el plan actual a partir del plan a largo plazo Si el plan actual, por alguna razón, ha pasado a estar inutilizable, puede crear un nuevo plan actual a partir del plan a largo plazo después de utilizar la función RENOVAR. Atención: Debe utilizar la función RENOVAR solo cuando no tenga otras alternativas, ya que suprime el plan actual. Asegúrese de que no puede realizar la recuperación utilizando el plan actual de copia de seguridad o el nuevo plan actual antes de utilizar RENOVAR. Para renovar el plan actual: 1. En el panel FUNCIÓN DE SERVICIO, seleccione la opción 5, RENOVAR (debe estar autorizado para utilizar esta función). El planificador visualiza un panel de confirmación. 2. Especifique Y para iniciar la renovación. La solicitud se envía al subsistema para que sea procesada por la tarea del gestor de modalidad normal. Si existen algunas estaciones de trabajo tolerantes a errores en la red, la tarea del gestor de modalidad normal les envía una solicitud de detención y, a continuación, actualiza el conjunto de datos de punto de comprobación y el conjunto de datos del plan a largo plazo para mostrar que el plan actual ya no existe. El gestor de modalidad normal detiene todos los lectores de sucesos activos y la función NCF si está activa. A partir de este momento, todos los diálogos que hacen referencia al plan actual dejan de estar disponibles. Para volver a crear el plan actual: 1. Entre en el diálogo de IBM Tivoli Workload Scheduler for z/OS y seleccione la opción 3, PLANIFICACIÓN DIARIA en el menú principal. 2. En el panel Producción del plan diario de OPC, seleccione la opción 2, AMPLIAR. Defina el inicio y fin del nuevo plan, y envíe el trabajo por lotes del plan diario para crear un nuevo plan actual. 3. En el panel Funciones de servicio, seleccione la opción 1, DESACTIVAR envío de trabajos. Capítulo 10. Copia de seguridad y recuperación de conjuntos de datos 361 Cómo volver a crear el plan actual a partir del plan a largo plazo 4. Cuando el trabajo por lotes crea un nuevo plan actual, IBM Tivoli Workload Scheduler for z/OS toma control de éste. A continuación, todos los diálogos de IBM Tivoli Workload Scheduler for z/OS vuelven a estar disponibles. Una vez que esto suceda, entre en el diálogo Modificar plan actual para establecer el estado correcto de todas las operaciones del plan actual. Todas las apariciones de aplicaciones que ya se han completado se deben suprimir, y las apariciones que están en curso se deben actualizar con la información actual. 5. Cuando se haya proporcionado a todas las operaciones el estado correcto, entre en el panel Funciones de servicio y habilite de nuevo el envío de trabajos. Nota: Si se selecciona la función de renovación por error, puede volver a crear el plan actual a partir del nuevo plan actual. Consulte “Cómo volver a crear el plan actual a partir del nuevo plan actual y del registro de archivado de JT”. Cómo volver a crear el plan actual a partir del nuevo plan actual y del registro de archivado de JT Si todos los conjuntos de datos del plan actual han resultado dañados o se han perdido pero el nuevo plan actual aún existe y es válido, es posible hacer que IBM Tivoli Workload Scheduler for z/OS tome control de nuevo del nuevo plan actual. Esta es una alternativa mejor que la utilización de la renovación ya que el plan actual resultante normalmente estará actualizado. Lleve a cabo el procedimiento siguiente: 1. Detenga IBM Tivoli Workload Scheduler for z/OS. 2. Añada la palabra clave CURRPLAN(NEW) a la sentencia JTOPTS. Cuando inicie IBM Tivoli Workload Scheduler for z/OS: a. Utilizará los nuevos conjuntos de datos del plan actual (EQQNCPDS y EQQNCXDS) como entrada b. Copiará EQQNCPDS en EQQCP1DS o EQQCP2DS c. Copiará EQQNCXDS en EQQCXDS y a continuación cargará el espacio de datos de CX de EQQCXDS. d. Aplicará todos los sucesos del registro de archivado de seguimiento de trabajos (EQQJTARC). Si IBM Tivoli Workload Scheduler for z/OS no ha finalizado normalmente, los sucesos se aplican también del registro de seguimiento de trabajos que se utilizaba cuando finalizó IBM Tivoli Workload Scheduler for z/OS. De esta forma, IBM Tivoli Workload Scheduler for z/OS vuelve a crear el plan actual. 3. Inicie IBM Tivoli Workload Scheduler for z/OS. 4. Elimine CURRPLAN(NEW) de la sentencia JTOPTS. Si planifica la característica global con capacidades de tolerancia a errores, realice las siguientes acciones manuales para asegurarse de que el archivo Symphony esté alineado con el plan actual que se ha vuelto a crear: 1. Desde el diálogo OPC, seleccione la opción 3, PLANIFICACIÓN DIARIA. Se visualiza el diálogo Producción de planes diarios de OPC. 2. A continuación, seleccione la opción 5, RENOVACIÓN DE SYMPHONY. 3. Envíe el trabajo por lotes de renovación de Symphony para crear un archivo Symphony alineado con el plan actual. 362 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Recuperación de errores en el registro de JT Recuperación de errores en el registro de seguimiento de trabajos IBM Tivoli Workload Scheduler for z/OS se recupera automáticamente de errores de lectura en un registro de seguimiento de trabajos durante el reinicio. Si el error se produce en la primera entrada del registro, la tarea NMM considera vacío el registro de seguimiento de trabajos. Un error de lectura en un registro que no sea el primero se trata como final de archivo. Cuando hay errores de grabación en el registro de seguimiento de trabajos, IBM Tivoli Workload Scheduler for z/OS intenta la recuperación. Si está disponible un registro de seguimiento de trabajos inactivo, IBM Tivoli Workload Scheduler for z/OS cambia a ese conjunto de datos y continúa el proceso. A continuación, puede concluir IBM Tivoli Workload Scheduler for z/OS para corregir el problema del conjunto de datos. Si IBM Tivoli Workload Scheduler for z/OS no puede cambiar a un registro de JT inactivo, debe hacer lo siguiente: 1. Detenga IBM Tivoli Workload Scheduler for z/OS. 2. Reasigne el conjunto de datos del registro de seguimiento de trabajos. 3. Si hay disponible un registro dual de JT, copie los datos del conjunto de datos del registro dual correspondiente en el nuevo conjunto de datos del registro de JT. 4. Inicie IBM Tivoli Workload Scheduler for z/OS. Si no utiliza la función de registro dual, perderá los datos de seguimiento de trabajos, pero el plan actual no debe resultar afectado. Sin embargo, es posible que resulte afectado de alguna forma si se requiere una recuperación en una etapa posterior del plan actual. Por lo tanto, amplíe o vuelva a planificar el plan actual lo antes posible. Problemas del conjunto de datos de registro dual de JT Cuando IBM Tivoli Workload Scheduler for z/OS encuentra un error en el conjunto de datos de seguimiento dual de trabajos, se inhabilita el proceso de registro dual. El plan actual de IBM Tivoli Workload Scheduler for z/OS y los registros de seguimiento normal de trabajos continúan de la forma habitual. Debe detener IBM Tivoli Workload Scheduler for z/OS y volver a asignar el conjunto de datos del registro dual de JT. La función de registro dual se activa de nuevo cuando se inicia el controlador. Recuperación de errores en el registro de archivado de JT Si hay un error de grabación en el registro de archivado de JT, realice el procedimiento siguiente: 1. Detenga IBM Tivoli Workload Scheduler for z/OS. 2. Renombre el conjunto de datos con un nombre temporal. 3. Asigne un nuevo conjunto de datos del registro de archivado de JT. 4. Copie el conjunto de datos anterior en el nuevo conjunto de datos. Esto lo puede hacer mediante IEBGENER o IDCAMS REPRO. 5. Inicie IBM Tivoli Workload Scheduler for z/OS. Si hay un error de lectura en el registro de archivado de JT, realice el procedimiento siguiente: 1. Detenga IBM Tivoli Workload Scheduler for z/OS. Capítulo 10. Copia de seguridad y recuperación de conjuntos de datos 363 Recuperación de errores en el registro de JT 2. Suprima el conjunto de datos y asigne un nuevo conjunto de datos de registro de archivado de JT. 3. Inicie IBM Tivoli Workload Scheduler for z/OS y envíe un trabajo de plan diario lo antes posible. La recuperabilidad del plan actual peligra mientras ejecuta un registro de archivado de JT incompleto. Atención: No inicie IBM Tivoli Workload Scheduler for z/OS con la palabra clave CURRPLAN(NEW) especificada en la sentencia JTOPTS hasta que IBM Tivoli Workload Scheduler for z/OS tome control de un nuevo plan actual. Recuperación de errores en el conjunto de datos de punto de comprobación Si hay un error de grabación en el conjunto de datos de punto de comprobación, realice el procedimiento siguiente: 1. Detenga IBM Tivoli Workload Scheduler for z/OS. 2. Renombre el conjunto de datos de punto de comprobación con un nombre temporal. 3. Asigne un nuevo conjunto de datos de punto de comprobación. 4. Copie el conjunto de datos de punto de comprobación anterior en el nuevo conjunto de datos. Esto lo puede hacer mediante ISPF COPY o IDCAMS REPRO. 5. Inicie de nuevo IBM Tivoli Workload Scheduler for z/OS. Si hay un error de lectura en el conjunto de datos de punto de comprobación, realice el procedimiento siguiente: v Si no existe un nuevo plan actual en buen estado: 1. Detenga IBM Tivoli Workload Scheduler for z/OS. 2. Suprima el conjunto de datos de punto de comprobación y vuélvalo a asignar. 3. Vuelva a crear el plan actual utilizando el procedimiento de renovación. Consulte “Cómo volver a crear el plan actual a partir del plan a largo plazo” en la página 361. v Si existe un conjunto de datos del nuevo plan actual en buen estado: 1. Detenga IBM Tivoli Workload Scheduler for z/OS. 2. Compruebe qué registro de seguimiento de trabajos es el actual. Esto se puede hacer revisando los mensajes del registro de mensajes o examinando el registro de JT y comprobando la indicación de fecha y hora en la posición 13 del primer registro del conjunto de datos. El conjunto de datos con la indicación de fecha y hora más reciente del primer registro es actual. 3. Copie los datos del registro de seguimiento de trabajos activos en el registro de seguimiento de trabajos al que hace referencia el ddname EQQJT01. 4. Determine qué archivo de JS está activo. Si EQQJS1DS define el conjunto de datos actual, continúe con el paso siguiente. De lo contrario, copie EQQJS2DS en EQQJS1DS o cambie los ddnames en el procedimiento de JCL. 5. Suprima y vuelva a asignar el conjunto de datos de punto de comprobación de IBM Tivoli Workload Scheduler for z/OS. 6. Cambie la sentencia JTOPTS para que especifique JOBSUBMIT(NO) y CURRPLAN(NEW) e inicie el planificador. 7. Entre en el diálogo Modificar plan actual para establecer el estado correcto para todas las operaciones del plan actual. 364 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Recuperación de errores en el conjunto de datos de punto de comprobación 8. Cuando todas las operaciones tengan el estado correcto, entre en el panel FUNCIONES DE SERVICIO y habilite de nuevo el envío de trabajos. Si la ha modificado, restaure la sentencia JTOPTS. Si planifica la característica global con capacidades de tolerancia a errores, realice las siguientes acciones manuales para asegurarse de que el archivo Symphony esté alineado con el plan actual que se ha vuelto a crear: 1. Desde el diálogo OPC, seleccione la opción 3, PLANIFICACIÓN DIARIA. Se visualiza el diálogo Producción de planes diarios de OPC. 2. A continuación, seleccione la opción 5, RENOVACIÓN DE SYMPHONY. 3. Envíe el trabajo por lotes de renovación de Symphony para crear un archivo Symphony alineado con el plan actual. Recuperación de errores en los conjuntos de datos de suceso Si un conjunto de datos de suceso (EQQEVDS o EQQHTTP0), un conjunto de datos de suceso de entrada (EQQTWSIN) o un conjunto de datos de suceso de salida (EQQTWSOU) se ha dañado, realice el procedimiento siguiente: 1. Detenga el subsistema IBM Tivoli Workload Scheduler for z/OS en el que está grabando o leyendo el conjunto de datos. 2. Renombre el conjunto de datos de suceso y asigne un nuevo conjunto de datos. 3. Inicie de nuevo IBM Tivoli Workload Scheduler for z/OS. Nota: La primera vez que IBM Tivoli Workload Scheduler for z/OS se inicia con un conjunto de datos de suceso recientemente asignado, se produce un error SD37 cuando IBM Tivoli Workload Scheduler for z/OS formatea el conjunto de datos. Esto es previsible; no lo considere un error. 4. Entre en el diálogo Modificar plan actual y compruebe el estado de las operaciones en el plan actual. Concéntrese en estaciones de trabajo con información automática cuyos sucesos se han grabado en el conjunto de datos de suceso dañado. Si se encuentra alguna discrepancia, establezca el estado correcto para la operación. Es poco probable que haya perdido algún suceso. Recuperación de errores en un conjunto de datos de envío/liberación Si se ha dañado un conjunto de datos de envío/liberación, realice el procedimiento siguiente: 1. Detenga el subsistema IBM Tivoli Workload Scheduler for z/OS en el que está grabando o leyendo el conjunto de datos. 2. Suprima el conjunto de datos de envío/liberación y asigne un nuevo conjunto de datos. 3. Inicie de nuevo IBM Tivoli Workload Scheduler for z/OS. Nota: La primera vez que IBM Tivoli Workload Scheduler for z/OS se inicia con un conjunto de datos de envío/liberación recientemente asignado, se produce un error SD37 cuando IBM Tivoli Workload Scheduler for z/OS formatea el conjunto de datos. Esto es previsible; no lo considere un error. 4. Entre en el diálogo Modificar plan actual y compruebe el estado de las operaciones en el plan actual. Concéntrese en estaciones de trabajo de sistema conectadas al controlador mediante el conjunto de datos de envío/liberación anómalo. Si determina que se ha perdido una acción de envío de trabajo, restablezca la operación en el estado PREPARADO. Capítulo 10. Copia de seguridad y recuperación de conjuntos de datos 365 Recuperación de errores en el conjunto de datos de ampliación del plan actual Recuperación de errores en el conjunto de datos de ampliación del plan actual IBM Tivoli Workload Scheduler for z/OS mantiene el archivo de ampliación del plan actual en un espacio de datos. El espacio de datos se carga desde el archivo EQQCXDS en DASD. Cuando se realiza una copia de seguridad del plan actual, el espacio de datos se renueva en el conjunto de datos EQQCXDS. Si se produce un error en el conjunto de datos, IBM Tivoli Workload Scheduler for z/OS intenta la recuperación inicial copiando el espacio de datos en el conjunto de datos. Si esto no es posible, se debe volver a crear el archivo. Si los conjuntos de datos EQQNCPDS y EQQNCXDS son válidos, realice las acciones siguientes: 1. Cancele IBM Tivoli Workload Scheduler for z/OS. 2. Asigne un nuevo conjunto de datos de CX. 3. Si ha asignado al conjunto de datos un nuevo nombre, actualice todos los JCL (ddname EQQCXDS) para que hagan referencia al nuevo conjunto de datos. 4. Especifique CURRPLAN(NEW) en la sentencia JTOPTS. 5. Inicie IBM Tivoli Workload Scheduler for z/OS. 6. Elimine CURRPLAN(NEW) de la sentencia JTOPTS. Si planifica la característica global con capacidades de tolerancia a errores, realice las siguientes acciones manuales para asegurarse de que el archivo Symphony esté alineado con el plan actual que se ha vuelto a crear: 1. Desde el diálogo OPC, seleccione la opción 3, PLANIFICACIÓN DIARIA. Se visualiza el diálogo Producción de planes diarios de OPC. 2. A continuación, seleccione la opción 5, RENOVACIÓN DE SYMPHONY. 3. Envíe el trabajo por lotes de renovación de Symphony para crear un archivo Symphony alineado con el plan actual. Si el conjunto de datos EQQNCXDS es válido pero existe un conjunto de datos EQQNCPDS no válido, realice las acciones siguientes: 1. Cancele IBM Tivoli Workload Scheduler for z/OS. 2. Asigne un nuevo conjunto de datos de CX. 3. Si ha asignado al conjunto de datos un nuevo nombre, actualice todos los JCL (ddname EQQCXDS) para que hagan referencia al nuevo conjunto de datos. 4. Copie EQQNCXDS en EQQCXDS. 5. Especifique CURRPLAN(CURRENT) en la sentencia JTOPTS. CURRENT es el valor predeterminado. 6. Inicie IBM Tivoli Workload Scheduler for z/OS. Si no se puede utilizar EQQNCPDS ni EQQNCXDS, debe crear un nuevo plan actual a partir del LTP. En “Cómo volver a crear el plan actual a partir del plan a largo plazo” en la página 361 se describe cómo hacerlo. Recuperación automática de anomalías del controlador Si el controlador o el sistema en el que se ejecuta falla, IBM Tivoli Workload Scheduler for z/OS puede transferir la función del controlador a otro sistema z/OS que ejecute IBM Tivoli Workload Scheduler for z/OS. Los sistemas implicados deben formar parte de un sysplex del recurso de acoplamiento entre sistemas (XCF). Se puede pasar automáticamente el control cuando IBM Tivoli Workload 366 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Recuperación automática de anomalías del controlador Scheduler for z/OS detecte una anomalía del comprobador de seguimiento o del sistema z/OS o se puede iniciar manualmente utilizando el mandato del operador MVS MODIFY. El sistema en espera al que se pasa el control debe tener disponibles todos los datos utilizados por el controlador original. Esto normalmente requiere la utilización de DASD compartido entre los dos sistemas. El nuevo sistema del controlador debe tener también acceso a todos los demás sistemas del complejo IBM Tivoli Workload Scheduler for z/OS mediante XCF, VTAM o conjuntos de datos de ENVÍO/LIBERACIÓN. Debe asegurarse de que estos enlaces estén disponibles. Además, el entorno de RACF del nuevo sistema z/OS del controlador debe estar configurado correctamente para garantizar que el nivel de acceso de usuario a los datos desde el sistema en espera es correcto. Para obtener más detalles sobre la espera dinámica de IBM Tivoli Workload Scheduler for z/OS, consulte la publicación Installation Guide. Notificación de anomalías del controlador Puede especificar que IBM Tivoli Workload Scheduler for z/OS genere un mensaje si el controlador o uno de sus componentes falla. Esta notificación se puede enviar a la consola del operador o directamente a NetView utilizando la interfaz de programa a programa de NetView. Puede especificar si el mensaje se debe generar, y su destino, utilizando la sentencia ALERTS. Para obtener información detallada sobre esta sentencia, consulte “ALERTS” en la página 10. Cómo volver a crear el archivo Symphony a partir del plan actual Si el proceso para crear el archivo Symphony falla, puede crear un nuevo archivo Symphony basado en el plan actual, si el plan está actualizado. Para obtener más información sobre la creación del archivo Symphony a partir del plan actual, consulte “Proceso de recuperación del plan actual” en la página 354. Para volver a crear el archivo Symphony: 1. Entre en el diálogo OPC y seleccione la opción 3, Planificación diaria, en el menú principal. 2. En el panel Producción de planes diarios de OPC, seleccione la opción 5, RENOVACIÓN DE SYMPHONY, y, a continuación, envíe el trabajo por lotes de renovación de Symphony para crear el archivo Symphony. Cuando el trabajo por lotes crea el archivo Symphony, se distribuye a la estación de trabajo tolerante a errores a fin de iniciar de nuevo la actividad de planificación. Capítulo 10. Copia de seguridad y recuperación de conjuntos de datos 367 Recuperación automática de anomalías del controlador 368 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Capítulo 11. Limpieza y recuperación de conjuntos de datos del almacén de datos El componente del almacén de datos está equipado con un conjunto de programas de utilidad que puede ejecutar en modalidad de proceso por lotes sólo cuando el almacén de datos no está en ejecución. Se produce una excepción sólo para el programa de utilidad de limpieza, que se puede ejecutar también como una subtarea del almacén de datos. En este caso, denominado 'modalidad en línea', el programa de utilidad se ejecutará periódicamente, y se suprimirán los registros seleccionados de la base de datos. Se recomienda encarecidamente que se utilice esta modalidad, a fin de asegurar una limpieza regular de los registros SYSOUT antiguos y mantener la base de datos en un tamaño razonable. Consulte a continuación para ver una descripción completa de la subtarea de limpieza. Cada programa de utilidad por lotes se activa mediante una palabra clave distinta del mandato DSTUTIL, tal y como se describe a continuación. Los programas de utilidad básicos son los siguientes: limpieza mandato DELUNSTR mandato DELSTRUC mandato DELBOTH exportación mandato EXPUNSTR mandato EXPSTRUC mandato EXPBOTH importación mandato IMPORT recuperación de índice primario mandato RECOVER recuperación de índice secundario se obtiene a partir del archivo de recuperación del índice primario Tanto para el índice primario como para el índice secundario se puede obtener otro programa de utilidad, reorg, combinando un programa de utilidad de exportación y un programa de utilidad de exportación. Supresión de datos de la base de datos Puede suprimir datos de la base de datos utilizando una de las palabras clave siguientes del mandato DSTUTIL: DELUNSTR Para suprimir los datos no estructurados DELSTRUC Para suprimir los datos estructurados DELBOTH Para suprimir los datos estructurados y no estructurados No es posible codificar acciones de limpieza para datos estructurados y no estructurados porque la subtarea de limpieza del almacén de datos acepta sólo una © Copyright IBM Corp. 1991, 2011 369 Supresión de datos de la base de datos sentencia DSTUTIL. Por lo tanto, para suprimir datos estructurados y no estructurados con sentencias DSTUTIL distintas, utilice el programa de utilidad de limpieza por lotes (ejemplo de limpieza por lotes EQQDSCL). El trabajo por lotes de limpieza se puede ejecutar sólo si el almacén de datos está detenido. Si decide planificar limpieza del almacén de datos utilizando el trabajo EQQDSCL, establezca DSTOPTS CINTERVAL(0). Para obtener detalles, consulte “DSTUTIL” en la página 51. Ejemplo: DSTUTIL DELUNSTR SEARCH1(JBNMLKJOB00*, SYCLEQU) SEARCH2(OLDRMM2) SEARCH3(JBIDEQJOB00467) Este mandato suprime los registros que coinciden con los criterios siguientes: JobName o bien job LIKE OLDER ’JOB00*’ y SysClass = ’U’ then 2 months o bien JobId = ’JOB00467’ Exportación de datos a un archivo de copia de seguridad Puede exportar registros SYSOUT seleccionados a un archivo secuencial utilizando una de las palabras clave siguientes del mandato DSTUTIL: EXPUNSTR Para exportar los datos no estructurados seleccionados a un archivo de exportación no estructurado EXPSTRUC Para exportar los datos estructurados seleccionados a un archivo de exportación estructurado EXPBOTH Para obtener, con un proceso de un único mandato, el resultado de dos mandatos precedentes. La palabra clave EXPUNSTR del mandato DSTUTIL se utiliza para exportar registros SYSOUT seleccionados en un archivo secuencial. Consulte Capítulo 1, “Definición de sentencias de inicialización”, en la página 5, en DSTUTIL, para obtener más detalles. Ejemplo: DSTUTIL IMPUNSTR DDNAME(EQQEXP01) SEARCH1(JBNMLKJOB*CC*,JBDTGE19990501) SEARCH2(JBDTGE19990515) Este mandato exporta los registros que coinciden con los criterios en un archivo secuencial identificado mediante el DDNAME EQQEXP01: JobName LIKE ’JOB*CC*’ y jobdate greater than or equal to 01/05/1999 o bien jobdate greater equal than 370 15/05/1999 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Importación de datos desde un archivo de copia de seguridad Importación de datos desde un archivo de copia de seguridad Los registros SYSOUT que se han exportado anteriormente en un archivo secuencial se pueden importar de nuevo en la base de datos utilizando la palabra clave IMPORT del mandato DSTUTIL. Sólo se importan los registros que coinciden con los criterios de la búsqueda. Consulte Capítulo 1, “Definición de sentencias de inicialización”, en la página 5, en DSTUTIL, para obtener más detalles. Ejemplo: DSTUTIL IMPORT DDNAME(EQQEXP01) REPLACE(YES) SEARCH1(JBIDLK*) Este mandato importa todos los registros SYSOUT contenidos en el archivo de exportación identificado mediante DDNAME EQQEXP01. La única condición especificada es un filtro de comodín que buscará coincidencias de todos los registros del archivo: JobId LIKE ’*’ La opción REPLACE(YES) significa que los registros coincidentes de la base de datos se sobrescribirán con los registros importados del archivo de copia de seguridad. Puede importar separadamente datos estructurados y no estructurados codificando el mandato IMPORT con dos ddnames distintos. El programa de utilidad de importación reconoce el tipo de datos de exportación (estructurado y no estructurado) debido al registro de cabecera que lo proporciona. Ejemplo DSTUTIL IMPORT DDNAME(EQQEXPST) REPLACE(YES) ← struct. exp. file SEARCH1(JBIDLK*) DSTUTIL IMPORT DDNAME(EQQEXPUN) REPLACE(YES) ← unstruct. exp. file SEARCH1(JBIDLK*) Nota: El mandato que se muestra más arriba se puede utilizar después de que se haya reorganizado toda la base de datos después de una exportación masiva anterior. Recuperación de anomalía La palabra clave RECOVER del mandato DSTUTIL analiza todos los registros de la base de datos y extrae las claves para cada uno. Esta información se graba en un archivo identificado por el ddname EQQPKREC (este nombre no se puede cambiar). El archivo obtenido de esta forma se puede utilizar para recuperar el índice primario y asegurar la coherencia de los datos. Además, el archivo de recuperación del índice secundario se puede obtener del archivo EQQPKREC, que representa la entrada a los procesos de recuperación. Este programa de utilidad es útil si alguno de los dos índices o los datos han resultado dañados. Para obtener más información, consulte Capítulo 1, “Definición de sentencias de inicialización”, en la página 5, en DSTUTIL. Qué hacer cuando se llenan los archivos de datos Si los archivos de VSAM del almacén de datos que ha definido son demasiado pequeños o no hay un número de ellos suficiente para almacenar todos los registros de trabajos que requiere que estén en línea, es posible que se encuentre con una condición de archivos llenos que cuelgue todas las actividades del almacén de datos. Si esto sucede, puede realizar dos acciones: Capítulo 11. Limpieza y recuperación de conjuntos de datos del almacén de datos 371 Qué hacer cuando se llenan los archivos de datos v Aumentar el tamaño de los archivos de datos, de índice secundario y de índice primario. v Definir algunos archivos de datos nuevos; para ello, debe definir uno o varios archivos de datos VSAM y añadirlos al procedimiento de inicio del almacén de datos, utilizando los DDNAME correctos consulte la publicación IBM Tivoli Workload Scheduler for z/OS Guía de planificación e instalación); los archivos se inicializan automáticamente en el primer inicio del almacén de datos. Nota: El índice primario siempre se reconstruye durante la fase de IMPORTACIÓN. También es posible combinar las dos estrategias. Subtarea de limpieza La subtarea de limpieza no es un programa de utilidad por lotes, sino un componente en línea del almacén de datos que es responsable de eliminar regularmente registros superfluos de la base de datos. Los registros que se seleccionarán para su supresión se identifican según los criterios definidos por el usuario, que se especifican en un miembro de la biblioteca de parámetros del almacén de datos. Normalmente, los registros con una antigüedad superior a un intervalo específico de tiempo, por ejemplo, 1 día, se suprimen, pero los criterios de supresión permiten tratar algunos trabajos de forma distinta de otros. El nombre del miembro que contiene los criterios de selección de limpieza se especifica en la sentencia de inicialización CLNPARM para el almacén de datos. La sintaxis de los criterios de selección es idéntica a la que se ha descrito para el programa de utilidad de limpieza por lotes anteriormente. Cuando codifique los criterios de selección, asegúrese de incluir un criterio que abarque todo que coincida con todos los registros y asegure que después de un periodo determinado de tiempo todos los registros finalmente se suprimirán. Es esencial que evite que con el tiempo el tamaño de la base de datos pase a ser demasiado grande y se llene, de forma que no se puedan almacenar más datos. Los errores de sintaxis de los criterios de selección de limpieza hacen que se cierre la tarea y que por lo tanto no se realicen las acciones de limpieza. En este caso, debe corregir los errores y reiniciar manualmente la tarea de limpieza, especificando S=ARCU en el mandato modify (P=ARCU detiene la subtarea). La subtarea de limpieza se activa periódicamente. La frecuencia con la que se activa la rige la sentencia de inicialización INTERVAL. Un valor de cero significa que la subtarea de limpieza del almacén de datos se inicia durante la inicialización del almacén de datos, pero nunca se ejecuta. Por lo tanto, si se establece CINTERVAL(0), el usuario debe planificar limpiezas por lotes regulares; de lo contrario, los archivos UDF y SDF del almacén de datos crecerán ilimitadamente. 372 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Capítulo 12. Planificación de recuperación tras desastre La Planificación de recuperación tras desastre (DRP) reduce el efecto negativo de un desastre en la empresa. DRP asegura que la impresa a la que da soporte el centro de datos permanece viable. En el caso de un desastre en el centro de datos primario, todas las operaciones y el trabajo de producción pasarían a un centro de datos secundario. Utilizando IBM Tivoli Workload Scheduler for z/OS para dirigir los esfuerzos de recuperación, puede asegurar que las recuperaciones necesarias se ejecutan secuencialmente, con retardos mínimos, y que se detecta y notifica cada uno de los errores. En este capítulo se describen las tareas siguientes: v Diseño de la DRP de IBM Tivoli Workload Scheduler for z/OS. v Implementación de la DRP de IBM Tivoli Workload Scheduler for z/OS. Antes de planificar la recuperación de datos, debe comprender bien todas las acciones de recuperación incorporadas proporcionadas por Tivoli Workload Scheduler for z/OS. Se recomienda la lectura siguiente: v El capítulo sobre configuraciones de IBM Tivoli Workload Scheduler for z/OS de la publicación Installation Guide v La información de consulta del plan actual en el capítulo sobre la generación del plan actual, que se describe en la publicación Managing the Workload v Capítulo 10, “Copia de seguridad y recuperación de conjuntos de datos”, en la página 351. Diseño de la DRP de Tivoli Workload Scheduler for z/OS La complejidad de la DRP de Tivoli Workload Scheduler for z/OS depende de las estrategias de recuperación de los sistemas empresariales. En las secciones siguientes se explican los procedimientos de un plan de recuperación de Tivoli Workload Scheduler for z/OS que se adecue de la mejor manera a las estrategias de DRP de su empresa: v Recuperación a inicio del día v Recuperación a un punto predefinido en el proceso v Recuperación a un punto de anomalía. Si la empresa utiliza más de una de estas estrategias de recuperación, la DRP se debe diseñar para la más compleja. Considere el ejemplo siguiente: En circunstancias normales, el centro de DP se ocupa del proceso de seis sistemas empresariales. Sólo cuatro de estos sistemas proporcionan recuperabilidad en otras instalaciones. Tres de los cuatro envían copias de seguridad en otras instalaciones cada hora; el otro sistema crea copias de seguridad cuando se completa el proceso cada día. La DRP de Tivoli Workload Scheduler for z/OS necesario para dar soporte a este entorno debe generar copias de seguridad en otras instalaciones cada hora. Después de que Tivoli Workload Scheduler for z/OS se haya recuperado a la copia de seguridad más reciente en el centro secundario, las apariciones de la aplicación para estos sistemas que recuperan al inicio del día se restablecen en estado de espera. Las apariciones no necesarias se suprimen del plan actual. Opciones del centro secundario El centro secundario determina la rapidez con la que puede obtener un entorno de IBM Tivoli Workload Scheduler for z/OS activo: © Copyright IBM Corp. 1991, 2011 373 Diseño de la planificación de recuperación tras desastre Copia de seguridad en caliente Un centro de datos secundario ya operativo y disponible para la conmutación inmediata Copia de seguridad en templado Un centro de datos secundario, posiblemente operativo, disponible para la conmutación después de cierto retardo (medido en horas o días) Copia de seguridad en frío Un centro de datos secundario con poco o ningún equipo instalado Agrupación Un centro de datos secundario o sitio en frío compartido por varios usuarios (o suscriptores). La distancia entre los centros a menudo es el factor determinante en la selección de las opciones de comunicación de la instalación. Los datos se deben llevar regularmente al centro de datos secundario desde el centro de datos primario para proporcionar copia de seguridad y recuperación de desastres. Esto se puede hacer mediante: v El transporte físico de los datos en un soporte (cinta, papel) v Las líneas de telecomunicación v Las conexiones de canal a canal v Los extensores de canal de fibra óptica. Si tiene DASD compartido con el centro secundario mediante conectores de canal a canal o mediante extensores de canal de fibra óptica, puede recuperar IBM Tivoli Workload Scheduler for z/OS al punto de anomalía utilizando los recursos de seguimiento dual de trabajos de IBM Tivoli Workload Scheduler for z/OS. A menos que el centro secundario sea una copia de seguridad en caliente que replique exactamente el centro de datos primario, debe identificar la configuración de IBM Tivoli Workload Scheduler for z/OS necesaria para dar soporte al entorno. Con el programador del sistema, identifique los subsistemas IBM Tivoli Workload Scheduler for z/OS necesarios. Estandarización del entorno En los casos donde sea posible, diseñe el entorno de forma que duplique la configuración del centro de datos primario lo máximo posible y adopte procedimientos para asegurar que los cambios de configuración y software aplicables se reflejen en el centro secundario. Convenios de denominación Intente utilizar los mismos nombres de subsistema, nombres de unidad lógica NCF y nombres de destino XCF. Esto puede ahorrarle tiempo en el proceso de recuperación y permite utilizar las mismas sentencias de inicialización que utilizaría normalmente en el centro primario. Requisitos de la biblioteca Los requisitos de SYS1.PARMLIB para dar soporte a la configuración del centro de datos secundario se deben definir de forma permanente en el SYSRES utilizado para el ejercicio de la DRP. Además, mantenga bibliotecas de software de IBM Tivoli Workload Scheduler for z/OS actualizadas en el centro secundario. Variaciones de capacidad y carga de trabajo Puede dirigir trabajo a la imagen de MVS necesaria cambiando las especificaciones de destino en las definiciones de estación de trabajo aplicables. Si el trabajo se 374 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Diseño de la planificación de recuperación tras desastre puede separar en unidades lógicas de proceso (por ejemplo, BMP de IMS o DB2), considere definir de forma permanente estas operaciones en estaciones de trabajo distintas. Esta implementación puede también proporcionar ventajas diarias para el proceso en el centro primario. Por ejemplo, si define todos los BMP de IMS en una estación de trabajo de procesador reservada para esta finalidad, tendrá más poder para controlar el proceso de las actividades, como por ejemplo: v Conclusión controlada de interrupciones de alimentación planificadas de la región de control v Variación del número de BMP que se ejecutan simultáneamente en función de la hora del día v Respuesta a tomas de control del recurso de recuperación ampliado (XRF) en casos en los que z/OS no resulta afectado v Manejo de la planificación de las operaciones durante interrupciones de alimentación no planificadas. Definiendo las operaciones de esta forma, puede mover toda la carga de trabajo a cualquier destino de la configuración de IBM Tivoli Workload Scheduler for z/OS. Consideraciones de JCL En los casos donde sea posible, estandarice los requisitos de JCL para las variables simbólicas, como por ejemplo clases SYSOUT y de entrada entre el centro primario y el centro secundario. Si las diferencias son inevitables, considere utilizar la función de sustitución de variables de JCL de IBM Tivoli Workload Scheduler for z/OS para reducir el efecto negativo de estos cambios. Las variables simbólicas se pueden definir de forma permanente en la tabla global de clases de entrada, clases SYSOUT y clases de almacenamiento SMS. La utilización de la sustitución de variables de JCL para estos elementos también impide los cambios de JCL en el centro primario. Consulte la publicación Managing the Workload para obtener información detallada. Automatización en el centro secundario El nivel de automatización en el centro primario determinará, hasta cierto punto, el entorno del centro secundario. Considere las recomendaciones siguientes: v No se debe utilizar la recuperación automática de trabajos hasta que los sistemas empresariales hayan completado como mínimo un ciclo de proceso completo. v El reinicio y redireccionamiento automáticos de la carga de trabajo se deben cambiar a control manual. v El atributo de informe de las estaciones de trabajo WTO se debe establecer a inicio manual y completarse si los servicios completos de NetView no están disponibles. v Continúe utilizando ETT si lo hace normalmente, pero si el plan actual no se extiende hasta la hora actual, las apariciones de la aplicación añadidas por ETT al CP fallarán. Cuando esto sucede, se emite un mensaje que identifica la aparición. A continuación, debe añadir manualmente la aplicación al plan. v La automatización implementada utilizando OPSTAT, EQQUSIN o EQQUSINT se puede manejar manualmente si el socio de automatización no está disponible. v En ejercicios de prueba de DRP, el atributo de informe para estaciones de trabajo controladas de forma remota no implicado en la prueba se debe establecer en no de informe. Capítulo 12. Planificación de recuperación tras desastre 375 Implementación de la planificación de recuperación tras desastre Implementación de la DRP de Tivoli Workload Scheduler for z/OS Los requisitos de copia de seguridad y el proceso de recuperación para cada una de las condiciones de DRP de IBM Tivoli Workload Scheduler for z/OS definidas se detallan en las secciones siguientes. El plan debe estar completamente documentado; no puede asumir que la persona con más experiencia en IBM Tivoli Workload Scheduler for z/OS estará disponible para llevar a cabo la recuperación. Si tanto el centro de datos primario como el centro de datos secundario utilizan DFSMS, considere utilizar DFSMShsm ABARS para la copia de seguridad y restauración de datos. ABARS simplifica el proceso de copia de seguridad y recuperación. Además, si define copias de seguridad para todos los conjuntos de datos con un nombre de conjunto de datos de alto nivel determinado, puede asegurar que se realiza copia de seguridad de todos los conjuntos de datos necesarios. Recuperación a proceso de inicio del día Un plan de recuperación tras desastre que recupera a proceso de inicio del día es, quizás, el proceso de copia de seguridad más sencillo de implementar. En el texto siguiente se describe la planificación de copia de seguridad necesaria para dar soporte al proceso de recuperación a proceso de inicio del día. Requisitos de copia de seguridad En la Tabla 39 se definen los intervalos de copia de seguridad necesarios para asegurar que puede restaurar IBM Tivoli Workload Scheduler for z/OS satisfactoriamente a proceso de inicio del día. N/A indica que una copia de seguridad no es aplicable para fines de DRP. Tabla 39. Ciclo de copia de seguridad para DRP a inicio del día ddname Formato Define Intervalo de copia de seguridad EQQADDS VSAM Aplicaciones y variables de JCL Diario EQQCKPT PS Conjunto de datos de punto de comprobación N/A EQQCP1DS VSAM Conjunto de datos de plan actual 1 N/A EQQCP2DS VSAM Conjunto de datos de plan actual 2 N/A EQQCXDS VSAM Conjunto de datos de ampliación de plan actual N/A EQQDLnn PS Conjunto de datos del registro de N/A seguimiento dual de trabajos EQQEVDS PS Conjunto de datos de suceso para N/A la tarea de grabador de sucesos EQQEVDnn PS Conjunto de datos de suceso para N/A la tarea de lector de sucesos EQQHTTP0 PS Conjunto de datos de sucesos para planificación global con capacidades z-centric EQQINCWK PS Archivo de trabajo de incidencias N/A de JCC 376 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste N/A Implementación de la planificación de recuperación tras desastre Tabla 39. Ciclo de copia de seguridad para DRP a inicio del día (continuación) ddname Formato Define Intervalo de copia de seguridad EQQJBLIB PDS Conjunto de datos de biblioteca de JCL Mínimo semanal, diario en caso de mucha actividad EQQJCLIB PDS Conjunto de datos de tabla de mensajes de JCC Mínimo semanal, N/A si es igual al primario EQQJS1DS VSAM Conjunto de datos de repositorio de JCL 1 N/A EQQJS2DS VSAM Conjunto de datos de repositorio de JCL 2 N/A EQQJTARC PS Conjunto de datos de archivado de seguimiento de trabajos N/A EQQJTnn PS Conjunto de datos de registro de seguimiento de trabajos N/A EQQLDDS VSAM Conjunto de datos de trabajo para trabajos por lotes de plan a largo plazo N/A EQQLTBKP VSAM Copia de seguridad de plan a largo plazo Vea la nota 1 EQQLTDS VSAM Conjunto de datos de plan a largo plazo Vea la nota 1 EQQMLIB PDS Biblioteca de mensajes N/A (ya en secundario) EQQMLOG PS Registro de mensajes N/A EQQNCPDS VSAM Conjunto de datos del nuevo plan actual N/A EQQNCXDS VSAM Conjunto de datos de ampliación del plan actual N/A EQQOIDS VSAM Base de datos de instrucciones del operador Mínimo semanal, diario en caso de mucha actividad EQQPARM PDS Biblioteca de parámetros de la sentencia de inicialización Mínimo semanal, diario en caso de mucha actividad Biblioteca de parámetros de la sentencia de inicialización EQQPRLIB PDS Biblioteca de procedimientos de recuperación automática Mínimo semanal, diario en caso de mucha actividad EQQRDDS VSAM Descripciones de recursos especiales Diario EQQSCLIB PDS Biblioteca de mandatos y scripts Mínimo semanal, diario en caso de mucha actividad EQQSIDS VSAM Datos de configuración y criterios Mínimo semanal, diario en de ETT caso de mucha actividad EQQSTC PDS Conjunto de datos de envío de tareas iniciadas N/A EQQSUDS PS Conjunto de datos de envío/liberación N/A EQQTWSCS PDSE Conjunto de datos global para soporte de script centralizado N/A Capítulo 12. Planificación de recuperación tras desastre 377 Implementación de la planificación de recuperación tras desastre Tabla 39. Ciclo de copia de seguridad para DRP a inicio del día (continuación) Intervalo de copia de seguridad ddname Formato Define EQQTWSIN PS Sucesos de entrada para planificación global con capacidades de tolerancia a errores N/A EQQTWSOU PS Sucesos de salida para planificación global con capacidades de tolerancia a errores N/A EQQWSDS VSAM Definiciones de estación de trabajo, calendario y periodo Mínimo semanal, diario en caso de mucha actividad EQQYPARM PDS Biblioteca de parámetros de sentencias de inicialización Mínimo semanal, diario en caso de mucha actividad STEPLIB PDS Biblioteca de módulos de carga de Tivoli Workload Scheduler for z/OS N/A (ya en secundario) definido por el usuario PS Conjunto de datos de envío/liberación N/A Notas: 1. Cuando se ejecuta un LTP o trabajo por lotes de planificación diaria, se graba una copia del LTP en el conjunto de datos EQQLTBKP. Utilice EQQLTBKP para las copias de seguridad de DRP para asegurarse de que no se han producido actualizaciones antes de que se realizara la copia de seguridad. Realice diariamente la copia de seguridad de DRP. 2. Tivoli Workload Scheduler for z/OS emite el mensaje EQQN057I para mostrar que se ha completado una copia de seguridad del CP. Debe actualizar el mensaje para que incluya WTO=YES de forma que pueda utilizar NetView para desencadenar copias de seguridad de conjunto de datos de DRP. El mensaje EQQN051I indica porqué se ha producido la copia de seguridad del CP. Se pueden desencadenar las copias de seguridad de DRP cuando el planificador emite el mensaje EQQN057I a continuación del mensaje EQQN051I con la razón "DP END". De hecho, en este momento, EQQLTBKP, EQQNCPDS y EQQNCXDS están todos ellos sincronizados con los demás datos del planificador. Proceso de recuperación Siga los pasos que se indican a continuación para recuperar el entorno de Tivoli Workload Scheduler for z/OS a proceso de inicio del día. 1. Asigne todos los conjuntos de datos necesarios. El JCL necesario se debe basar en los miembros de la biblioteca de ejemplos (SEQQSAMP) EQQPCS01 y EQQPCS02. 2. Restaure los datos de la última copia de seguridad realizada antes del inicio de día necesario. Por ejemplo, si es necesaria la recuperación al inicio del día del martes, se deberán utilizar las copias de seguridad del lunes para la recuperación. 3. Especifique JOBSUBMIT (NO) y CURRPLAN (NEW) en la sentencia JTOPTS y, a continuación, inicie el espacio de direcciones del controlador. Inicie los espacios de direcciones adicionales para los subsistemas del comprobador de seguimiento. 4. Si es necesario, utilice la función de actualización masiva del diálogo Descripción de la aplicación para crear sistemas empresariales sin efecto que no necesitará para procesar el centro secundario. 5. Envíe un trabajo por lotes MODIFY ALL del plan a largo plazo. 378 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Implementación de la planificación de recuperación tras desastre 6. Envíe una PRUEBA del plan diario para el periodo de planificación necesario y compruebe los resultados. Se recomienda que inicie el periodo de planificación a las 00:00 de la fecha necesaria para reducir el número de apariciones no decididas incluidas en el plan actual. 7. Envíe un trabajo por lotes EXTEND del plan diario para el periodo de planificación necesario. Utilice 00:00 como hora de inicio. Cuando se cree el nuevo plan actual, utilice los diálogos de Tivoli Workload Scheduler for z/OS para comprobar que las apariciones y los recursos están en el estado correcto antes de iniciar el envío de trabajos. 8. Cambie CURRPLAN(NEW) a CURRPLAN(CURRENT) en la sentencia JTOPTS. Recuperación a un punto de recuperación predefinido Este proceso de copia de seguridad y recuperación se puede utilizar cuando la estrategia de DRP invoca la recuperación a un momento determinado o a un punto específico del ciclo de proceso. Esto se podría hacer una vez al día o cada hora. El proceso es el mismo independientemente de la regularidad con la que necesite realizar las copias de seguridad. Requisitos de copia de seguridad En la Tabla 40 se definen los intervalos de copia de seguridad necesarios para asegurar que puede restaurar satisfactoriamente IBM Tivoli Workload Scheduler for z/OS a un punto de recuperación predefinido. No se debe realizar copia de seguridad de todos los conjuntos de datos en el punto notificado del proceso. De aquellos de los que sí se debe realizar copia de seguridad, ésta se debe realizar sólo después de que controlador haya procesado el mandato BACKUP para los recursos de CP y JS. N/A indica que una copia de seguridad no es aplicable para fines de DRP. Tabla 40. Ciclo de copia de seguridad para DRP a punto de recuperación predefinido ddname Formato Define Intervalo de copia de seguridad EQQADDS VSAM Aplicaciones y variables de JCL Diario EQQCKPT PS Conjunto de datos de punto de comprobación N/A EQQCP1DS VSAM Conjunto de datos de plan actual 1 N/A EQQCP2DS VSAM Conjunto de datos de plan actual 2 N/A EQQCXDS VSAM Conjunto de datos de ampliación de plan actual N/A EQQDLnn PS Conjunto de datos del registro de N/A seguimiento dual de trabajos EQQEVDS PS Conjunto de datos de suceso para N/A la tarea de grabador de sucesos EQQEVDnn PS Conjunto de datos de suceso para N/A la tarea de lector de sucesos EQQHTTP0 PS Conjunto de datos de sucesos para planificación global con capacidades z-centric EQQINCWK PS Archivo de trabajo de incidencias N/A de JCC N/A Capítulo 12. Planificación de recuperación tras desastre 379 Implementación de la planificación de recuperación tras desastre Tabla 40. Ciclo de copia de seguridad para DRP a punto de recuperación predefinido (continuación) ddname Formato Define Intervalo de copia de seguridad EQQJBLIB PDS Conjunto de datos de biblioteca de JCL Mínimo semanal, diario en caso de mucha actividad EQQJCLIB PDS Conjunto de datos de tabla de mensajes de JCC Mínimo semanal, N/A si es igual al primario EQQJS1DS VSAM Conjunto de datos de repositorio de JCL 1 Hora predefinida (vea la nota 1) EQQJS2DS VSAM Conjunto de datos de repositorio de JCL 2 Hora predefinida (vea la nota 1) EQQJTARC PS Conjunto de datos de archivado de seguimiento de trabajos N/A EQQJTnn PS Conjunto de datos de registro de seguimiento de trabajos N/A EQQLDDS VSAM Conjunto de datos de trabajo para trabajos por lotes de plan a largo plazo N/A EQQLTBKP VSAM Copia de seguridad de plan a largo plazo Vea la nota 2 EQQLTDS VSAM Conjunto de datos de plan a largo plazo Vea la nota 2 EQQMLIB PDS Biblioteca de mensajes N/A (ya en secundario) EQQMLOG PS Registro de mensajes N/A EQQNCPDS VSAM Conjunto de datos del nuevo plan actual Después de cada NCP EQQNCXDS VSAM Conjunto de datos de ampliación del plan actual Después de cada NCP EQQOIDS VSAM Base de datos de instrucciones del operador Mínimo semanal, diario en caso de mucha actividad EQQPARM PDS Biblioteca de parámetros de la sentencia de inicialización Mínimo semanal, diario en caso de mucha actividad Biblioteca de parámetros de la sentencia de inicialización EQQPRLIB PDS Biblioteca de procedimientos de recuperación automática Mínimo semanal, diario en caso de mucha actividad EQQRDDS VSAM Descripciones de recursos especiales Diario EQQSCLIB PDS Biblioteca de descripciones de mandatos y scripts Mínimo semanal, diario en caso de mucha actividad EQQSIDS VSAM Datos de configuración y criterios Mínimo semanal, diario en de ETT caso de mucha actividad EQQSTC PDS Conjunto de datos de envío de tareas iniciadas N/A EQQSUDS PS Conjunto de datos de envío/liberación N/A EQQTWSCS PDSE Conjunto de datos global para soporte de script centralizado N/A 380 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Implementación de la planificación de recuperación tras desastre Tabla 40. Ciclo de copia de seguridad para DRP a punto de recuperación predefinido (continuación) Intervalo de copia de seguridad ddname Formato Define EQQTWSIN PS Sucesos de entrada para planificación global con capacidades de tolerancia a errores N/A EQQTWSOU PS Sucesos de salida para planificación global con capacidades de tolerancia a errores N/A EQQWSDS VSAM Definiciones de estación de trabajo, calendario y periodo Mínimo semanal, diario en caso de mucha actividad STEPLIB PDS Biblioteca de módulos de carga de Tivoli Workload Scheduler for z/OS N/A (ya en secundario) definido por el usuario PS Conjunto de datos de envío/liberación N/A Notas: 1. EQQJSnDS: cuando se complete la copia de seguridad de JS solicitada, realice una copia de seguridad del archivo inactivo. Tivoli Workload Scheduler for z/OS emite el mensaje EQQN015I para indicar que la copia se ha completado y para identificar el ddname de JS inactivo. Debe actualizar el mensaje para que incluya WTO=YES para desencadenar la copia de seguridad utilizando NetView. 2. Cuando se ejecuta un LTP o trabajo por lotes de planificación diaria, se graba una copia del LTP en el conjunto de datos EQQLTBKP. Utilice EQQLTBKP para las copias de seguridad de DRP para asegurarse de que no se han producido actualizaciones antes de que se realizara la copia de seguridad. Realice la copia de seguridad de DRP después de cada NCP. 3. Tivoli Workload Scheduler for z/OS emite el mensaje EQQN057I para mostrar que se ha completado una copia de seguridad del CP. Debe actualizar el mensaje para que incluya WTO=YES de forma que pueda utilizar NetView para desencadenar copias de seguridad de conjunto de datos de DRP. El mensaje EQQN051I indica porqué se ha producido la copia de seguridad del CP. Se pueden desencadenar las copias de seguridad de DRP cuando el planificador emite el mensaje EQQN057I a continuación del mensaje EQQN051I con la razón "DP END". De hecho, en este momento, EQQLTBKP, EQQNCPDS y EQQNCXDS están todos ellos sincronizados con los demás datos del planificador. Proceso de recuperación Siga los pasos que se indican a continuación para recuperar el entorno de Tivoli Workload Scheduler for z/OS a un punto predefinido del proceso. 1. Asigne todos los conjuntos de datos necesarios. El JCL necesario se debe basar en los miembros de la biblioteca de ejemplos (SEQQSAMP) EQQPCS01 y EQQPCS02. 2. Los datos de los que se realiza copia de seguridad diaria o semanalmente se deben recuperar a partir de la copia de seguridad más reciente. LTP y NCP también se deben recuperar a partir de la copia de seguridad más reciente. 3. Restaure los datos de los que se ha hecho copia de seguridad al punto predefinido. Copie la copia de seguridad de JS en EQQJS1DS y EQQJS2DS. 4. Especifique JOBSUBMIT (NO) y CURRPLAN (NEW) en la sentencia JTOPTS y, a continuación, inicie el espacio de direcciones del controlador. Inicie los espacios de direcciones adicionales necesarios para los subsistemas del comprobador de seguimiento. Capítulo 12. Planificación de recuperación tras desastre 381 Implementación de la planificación de recuperación tras desastre 5. Utilice los diálogos de Tivoli Workload Scheduler for z/OS para suprimir o completar apariciones que no necesite procesar en el centro secundario. Compruebe el estado de todas las apariciones y los recursos especiales antes de iniciar el envío de trabajos. 6. Cambie CURRPLAN(NEW) a CURRPLAN(CURRENT) en la sentencia JTOPTS. Si planifica la característica global con capacidades de tolerancia a errores, realice las siguientes acciones manuales para asegurarse de que el archivo Symphony esté alineado con el plan actual que se ha vuelto a crear: 1. En el diálogo de Tivoli Workload Scheduler for z/OS seleccione la opción 3, PLANIFICACIÓN DIARIA. Se visualiza el diálogo Producción de planes diarios de OPC. 2. Seleccione la opción 5, RENOVACIÓN DE SYMPHONY. 3. Envíe el trabajo por lotes de renovación de Symphony para crear un archivo Symphony alineado con el plan actual. Recuperación a punto de anomalía Este proceso de copia de seguridad y recuperación se utiliza para recuperar el entorno de Tivoli Workload Scheduler for z/OS a un punto de anomalía. La estrategia se basa en el recurso de seguimiento dual de trabajos. Los registros duales se pueden asignar en DASD en el centro secundario conectado al centro primario mediante conectores de canal a canal o extensores de canal de fibra óptica. Aunque el proceso de copia de seguridad es complejo, cuando está en vigor esta configuración proporciona recuperación rápida del entorno. Requisitos de copia de seguridad En la Tabla 41 se definen los intervalos de copia de seguridad necesarios para asegurar que puede restaurar satisfactoriamente a un punto de anomalía. De algunos conjuntos de datos es necesario realizar copia de seguridad sólo semanalmente; de otros es necesario realizar copia de seguridad después de cada copia de seguridad de CP o JS. N/A indica que una copia de seguridad no es aplicable para fines de DRP. Tabla 41. Ciclo de copia de seguridad para DRP a punto de anomalía ddname Formato Define Intervalo de copia de seguridad EQQADDS VSAM Aplicaciones y variables de JCL Diario EQQCKPT PS Conjunto de datos de punto de comprobación N/A EQQCP1DS VSAM Conjunto de datos de plan actual 1 N/A EQQCP2DS VSAM Conjunto de datos de plan actual 2 N/A EQQCXDS VSAM Conjunto de datos de ampliación de plan actual N/A EQQDLnn PS Conjunto de datos del registro de N/A (ya en secundario) seguimiento dual de trabajos EQQEVDS PS Conjunto de datos de suceso para N/A la tarea de grabador de sucesos 382 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Implementación de la planificación de recuperación tras desastre Tabla 41. Ciclo de copia de seguridad para DRP a punto de anomalía (continuación) Intervalo de copia de seguridad ddname Formato Define EQQEVDnn PS Conjunto de datos de suceso para N/A la tarea de lector de sucesos EQQHTTP0 PS Conjunto de datos de sucesos para planificación global con capacidades z-centric EQQINCWK PS Archivo de trabajo de incidencias N/A de JCC EQQJBLIB PDS Conjunto de datos de biblioteca de JCL Mínimo semanal, diario en caso de mucha actividad EQQJCLIB PDS Conjunto de datos de tabla de mensajes de JCC Mínimo semanal, N/A si es igual al primario EQQJS1DS VSAM Conjunto de datos de repositorio de JCL 1 Vea la nota 1 EQQJS2DS VSAM Conjunto de datos de repositorio de JCL 2 Vea la nota 1 EQQJTARC PS Conjunto de datos de archivado de seguimiento de trabajos Vea la nota 2 EQQJTnn PS Conjunto de datos de registro de seguimiento de trabajos N/A EQQLDDS VSAM Conjunto de datos de trabajo para trabajos por lotes de plan a largo plazo N/A EQQLTBKP VSAM Copia de seguridad de plan a largo plazo Vea la nota 3 EQQLTDS VSAM Conjunto de datos de plan a largo plazo Vea la nota 3 EQQMLIB PDS Biblioteca de mensajes N/A (ya en secundario) EQQMLOG PS Registro de mensajes N/A EQQNCPDS VSAM Conjunto de datos del nuevo plan actual Después de cada NCP EQQNCXDS VSAM Conjunto de datos de ampliación del plan actual Después de cada NCP EQQOIDS VSAM Base de datos de instrucciones del operador Mínimo semanal, diario en caso de mucha actividad EQQPARM PDS Biblioteca de parámetros de la sentencia de inicialización Mínimo semanal, diario en caso de mucha actividad N/A Biblioteca de parámetros de la sentencia de inicialización EQQPRLIB PDS Biblioteca de procedimientos de recuperación automática Mínimo semanal, diario en caso de mucha actividad EQQRDDS VSAM Descripciones de recursos especiales Diario EQQSCLIB PDS Biblioteca de definiciones de scripts y mandatos Mínimo semanal, diario en caso de mucha actividad EQQSIDS VSAM Datos de configuración y criterios Mínimo semanal, diario en de ETT caso de mucha actividad Capítulo 12. Planificación de recuperación tras desastre 383 Implementación de la planificación de recuperación tras desastre Tabla 41. Ciclo de copia de seguridad para DRP a punto de anomalía (continuación) Intervalo de copia de seguridad ddname Formato Define EQQSTC PDS Conjunto de datos de envío de tareas iniciadas N/A EQQSUDS PS Conjunto de datos de envío/liberación N/A EQQTWSCS PDSE Conjunto de datos global para soporte de script centralizado N/A EQQTWSIN PS Sucesos de entrada para planificación global con capacidades de tolerancia a errores N/A EQQTWSOU PS Sucesos de salida para planificación global con capacidades de tolerancia a errores N/A EQQWSDS VSAM Definiciones de estación de trabajo, calendario y periodo Mínimo semanal, diario en caso de mucha actividad STEPLIB PDS Biblioteca de módulos de carga de IBM Tivoli Workload Scheduler for z/OS N/A, ya en secundario definido por el usuario PS Conjunto de datos de envío/liberación N/A Notas: 1. EQQJSnDS: cada vez que se complete una copia de JS, realice una copia de seguridad del archivo inactivo. Tivoli Workload Scheduler for z/OS emite el mensaje EQQN015I para indicar que la copia se ha completado y para identificar el ddname de JS inactivo. Debe actualizar el mensaje para que incluya WTO=YES para desencadenar la copia de seguridad utilizando NetView. 2. EQQJTARC: después de cada copia de seguridad de CP, el contenido del registro de seguimiento de trabajos actual se copia en este conjunto de datos. Realice la copia de seguridad después de que se emita el mensaje EQQN090I para indicar que los datos de JT se han copiado en el conjunto de datos de archivado. 3. Cuando se ejecuta un LTP o trabajo por lotes de planificación diaria, se graba una copia del LTP en el conjunto de datos EQQLTBKP. Utilice EQQLTBKP para las copias de seguridad de DRP para asegurarse de que no se han producido actualizaciones antes de que se realizara la copia de seguridad. Realice la copia de seguridad de DRP después de cada NCP. 4. Tivoli Workload Scheduler for z/OS emite el mensaje EQQN057I para mostrar que se ha completado una copia de seguridad del CP. Debe actualizar el mensaje para que incluya WTO=YES de forma que pueda utilizar NetView para desencadenar copias de seguridad de conjunto de datos de DRP. El mensaje EQQN051I indica porqué se ha producido la copia de seguridad del CP. Se pueden desencadenar las copias de seguridad de DRP cuando el planificador emite el mensaje EQQN057I a continuación del mensaje EQQN051I con la razón "DP END". De hecho, en este momento, EQQLTBKP, EQQNCPDS y EQQNCXDS están todos ellos sincronizados con los demás datos del planificador. Proceso de recuperación Siga los pasos que se indican a continuación para recuperar el entorno de Tivoli Workload Scheduler for z/OS a un punto de anomalía. 1. Asigne todos los conjuntos de datos necesarios. El JCL necesario se debe basar en los miembros de la biblioteca de ejemplos (SEQQSAMP) EQQPCS01 y EQQPCS02. 384 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Implementación de la planificación de recuperación tras desastre 2. Los datos de los que se realiza copia de seguridad diaria o semanalmente se deben recuperar a partir de la copia de seguridad más reciente. LTP, NCP y JTARC se deben recuperar a partir de la copia de seguridad más reciente. 3. Restaure los datos de los que se ha realizado copia de seguridad a intervalos regulares. Copie la copia de seguridad de JS en EQQJS1DS y EQQJS2DS. 4. Examine EQQJTARC y obtenga la indicación de fecha y hora del último registro. La indicación de fecha y hora se inicia en la ubicación decimal 12 y tiene el formato 00AAMMDDFHHMMSSTH. Examine los conjuntos de datos EQQDLnn e identifique los archivos que contengan registros de seguimiento de trabajos no incluidos en el registro de archivado. 5. Copie el conjunto de datos EQQDLnn necesario en EQQJT01. Si más de un registro dual contiene datos de seguimiento de trabajos no incluidos en el registro de archivado, añada todos los registros a EQQJT01 en estricto orden temporal. 6. Especifique JOBSUBMIT (NO) y CURRPLAN (NEW) en la sentencia JTOPTS y, a continuación, inicie el espacio de direcciones del controlador. Inicie los espacios de direcciones adicionales necesarios para los subsistemas del comprobador de seguimiento. 7. Utilice los diálogos de Tivoli Workload Scheduler for z/OS para suprimir o completar apariciones que no necesite procesar en el centro secundario. Compruebe el estado de todas las apariciones y recursos antes de iniciar el envío de trabajos. 8. Cambie CURRPLAN(NEW) a CURRPLAN(CURRENT) en la sentencia JTOPTS. Si planifica la característica global con capacidades de tolerancia a errores, realice las siguientes acciones manuales para asegurarse de que el archivo Symphony esté alineado con el plan actual que se ha vuelto a crear: 1. En el diálogo de Tivoli Workload Scheduler for z/OS seleccione la opción 3, PLANIFICACIÓN DIARIA. Se visualiza el diálogo Producción de planes diarios de OPC. 2. Seleccione la opción 5, RENOVACIÓN DE SYMPHONY. 3. Envíe el trabajo por lotes de renovación de Symphony para crear un archivo Symphony alineado con el plan actual. | | Consideraciones sobre pruebas de recuperación tras desastre en un entorno global | | | | | | | Durante una recuperación tras desastre, USS BINDIR (ya sea HFS o ZFS) también se restaura. Si prueba una recuperación tras desastre mientras el entorno de producción sigue en ejecución, las direcciones IP que contiene el archivo Symphony puede hacer que los agentes con tolerancia a errores se cierren de forma inesperada. Para evitar este problema, WRKDIR no debe restaurarse en el sito de recuperación tras desastre o el archivo Symphony debe suprimirse antes de iniciar el servidor global en el sitio de recuperación tras desastre. | | | | | Por lo tanto, si prueba una recuperación tras desastre, lleve a cabo una de estas acciones: v No restaure WRKDIR en el sitio de recuperación tras desastre. En lugar de ello, ejecute el trabajo EQQPCS05 para crear un WRKDIR vacío y luego inicie el servidor global y ejecute SYMPHONY RENEW. Capítulo 12. Planificación de recuperación tras desastre 385 Implementación de la planificación de recuperación tras desastre v Tras restaurar el WRKDIR de producción y antes de iniciar el controlador y el servidor global, suprima o cambie el nombre de los archivos Symphony y translator.chk desde WRKDIR. Inicie el controlador y el servidor global, y luego ejecute SYMPHONY RENEW. | | | | 386 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Parte 3. Ajuste Capítulo 13. Análisis del rendimiento . . . . Establecimiento de los objetivos de rendimiento Medición del rendimiento . . . . . . . . . Performance Reporter for MVS y Tivoli Decision Support for OS/390 . . . . . . . . . . RMF . . . . . . . . . . . . . . . ACF/VTAM . . . . . . . . . . . . . VSAM . . . . . . . . . . . . . . . Datos de rendimiento de Tivoli Workload Scheduler for z/OS . . . . . . . . . . 389 389 390 390 391 393 393 393 Capítulo 14. Actividades básicas de ajuste . . 395 Recursos del sistema . . . . . . . . . . . 395 Actividad de E/S . . . . . . . . . . . 395 Eliminación de procesos innecesarios . . . 396 Definiciones de clústeres de VSAM . . . . 397 Colocación de conjuntos de datos . . . . 398 Opciones de rendimiento de hardware . . . 398 Procesador . . . . . . . . . . . . . 399 Almacenamiento del procesador . . . . . . 399 Problemas de paginación . . . . . . . 400 Indicadores de problemas relacionados con el rendimiento . . . . . . . . . . . . . . 401 Cómo evitar cuellos de botella. . . . . . . . 401 Capítulo 15. Ajuste del controlador y del rastreador . . . . . . . . . . . . . . 403 Ajuste del controlador . . . . . . . . . . 403 Envío de trabajos . . . . . . . . . . . 403 Cómo reconocer los indicadores . . . . . 403 Desglose del proceso . . . . . . . . . 404 Recomendaciones . . . . . . . . . . 404 Seguimiento de trabajos . . . . . . . . . 405 Cómo reconocer los indicadores . . . . . 405 Recomendaciones . . . . . . . . . . 405 Respuesta del diálogo . . . . . . . . . 406 Factores que influencian los tiempos de respuesta . . . . . . . . . . . . . 406 Recomendaciones . . . . . . . . . . 406 Proceso por lotes en segundo plano . . . . . . 406 Cómo reconocer los indicadores . . . . . . 407 Recomendaciones . . . . . . . . . . . 407 Ajuste del rastreador . . . . . . . . . . . 407 Creación y comunicación de sucesos. . . . . 407 Factores que afectan al rendimiento . . . . . 407 Recomendaciones . . . . . . . . . . 408 JCC . . . . . . . . . . . . . . . 408 Medición del rendimiento de JCC . . . . 408 Recomendaciones . . . . . . . . . . 409 Reinicio y limpieza . . . . . . . . . . . 409 © Copyright IBM Corp. 1991, 2011 387 388 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Capítulo 13. Análisis del rendimiento Esta parte de la publicación describe cómo es posible mejorar el rendimiento de IBM Tivoli Workload Scheduler for z/OS. También proporciona información de consulta para ayudarle a conseguir esta mejora. Un buen rendimiento es el logro de los niveles de servicio acordados. Esto significa que la disponibilidad, rendimiento y tiempos de respuesta del sistema cumplen las expectativas del usuario que utiliza los recursos disponibles dentro del presupuesto. Se debe considerar el rendimiento de IBM Tivoli Workload Scheduler for z/OS cuando: v Planee instalar un nuevo sistema v Desee revisar un sistema existente v Contemple realizar cambios importantes en un sistema. Existen algunas etapas básicas de los ajustes de un sistema, algunas de las cuales es posible que sean repetitivas hasta que el rendimiento sea aceptable. Éstas son las siguientes: v Acordar qué se considera un buen rendimiento v Configurar los objetivos de rendimiento v Decidir sobre los criterios de medición v Medir el rendimiento del sistema de producción v Realizar ajustes según sea necesario v Continuar supervisando el rendimiento del sistema y anticipar futuras restricciones. Las recomendaciones que se proporcionan en esta publicación, basadas en los conocimientos que se tienen actualmente de IBM Tivoli Workload Scheduler for z/OS, son de tipo genérico y no pueden garantizar la mejora del rendimiento de un sistema determinado. Establecimiento de los objetivos de rendimiento Los objetivos de rendimiento a menudo consisten en una tasa de rendimiento además de una lista de funciones de diálogos o procesos por lotes y los tiempos que se esperan para cada uno de ellos. Idealmente, mediante éstos se puede reconocer fácilmente un buen rendimiento y saber cuándo dejar de realizar más ajustes. Por lo tanto, deben cumplir las condiciones siguientes: v Ser medibles de forma práctica v Estar basados en una carga de trabajo realista v Estar dentro del presupuesto. Es posible que estos objetivos se definan en términos como por ejemplo: v Tiempos de respuesta deseados o aceptables, por ejemplo, dentro de los cuales se produzcan el 90% de todas las respuestas. v Número promedio o de hora punta de operaciones controladas a través del sistema. v Disponibilidad del sistema, incluido tiempo medio para anomalía, y recuperación tras una anomalía. © Copyright IBM Corp. 1991, 2011 389 Medición del rendimiento Medición del rendimiento Después de haber definido la carga de trabajo y estimado los recursos necesarios, debe reconciliar la respuesta que desea con la que se considera realizable. El rendimiento de un sistema de producción depende de los requisitos de uso, tasas de paginación y almacenamiento virtual en el procesador principal, el tráfico a y de los dispositivos de disco, el tráfico de mensajes a través de la red y una variedad de otros factores. Debe supervisar todos estos factores para determinar las restricciones que es posible que se desarrollen en el sistema. Se podrían escribir diversos programas para supervisar todos estos recursos. Algunos de estos programas se proporcionan actualmente como parte de productos IBM como por ejemplo IBM Tivoli Workload Scheduler for z/OS o bien como productos aparte. En este tema se describen algunos de los programas que pueden proporcionar información de rendimiento sobre diversos componentes de un sistema de producción. La lista de productos que aparece en este tema no es ni mucho menos un resumen exhaustivo de las herramientas de supervisión de rendimiento, pero los datos proporcionados a partir de estas fuentes contienen gran cantidad de información. La supervisión de todos estos datos es una amplia tarea. Además, sólo un pequeño subconjunto de la información proporcionada es importante para identificar las restricciones y determinar las acciones de ajuste necesarias, y debe identificar este subconjunto específico. A menudo debe reunir muchos datos antes de poder comprender plenamente el comportamiento de su propio sistema y determinar dónde un esfuerzo de ajuste puede proporcionar la mejora de rendimiento global más adecuada. Debe estar familiarizado con las herramientas de análisis y los datos que proporcionan para ajustar correctamente el sistema. Pero recuerde que la utilización de cualquier herramienta de supervisión tiene un coste de esfuerzo de proceso. Performance Reporter for MVS y Tivoli Decision Support for OS/390 Performance Reporter for MVS (anteriormente Performance Data Manager for MVS) y Tivoli Decision Support for OS/390 son productos IBM que recopilan y analizan datos de IBM Tivoli Workload Scheduler for z/OS y otros sistemas y productos IBM. Puede crear informes que le ayuden en las tareas siguientes: v Visiones generales del sistema v Niveles de servicio v Disponibilidad v Rendimiento y ajuste v Planificación de capacidad v Gestión de cambios y problemas v Compatibilidad. Hay disponibles muchos informes predefinidos. También puede generar sus propios informes para que se adecuen a sus necesidades específicas. Los informes utilizan datos de los archivos de seguimiento de trabajos de IBM Tivoli Workload Scheduler for z/OS. Performance Reporter for MVS y Tivoli Decision Support for OS/390 también recopilan datos del sistema MVS y de productos como por ejemplo RMF, TSO, IMS y NetView. Esto significa que los datos de IBM Tivoli Workload Scheduler for z/OS y de otros sistemas se pueden mostrar conjuntamente, o bien se pueden presentar en informes distintos. 390 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Medición del rendimiento Los informes se pueden presentar como trazos, diagramas de barras, diagramas circulares, diagramas de torres, histogramas, diagramas de superficie y otros formatos gráficos. Performance Reporter for MVS y Tivoli Decision Support for OS/390 simplemente pasan los datos y los detalles de formateo a Graphic Data Display Manager (GDDM), que se encarga del resto. Performance Reporter for MVS y Tivoli Decision Support for OS/390 también pueden generar gráficos de líneas e histogramas utilizando gráficos de caracteres, donde GDDM no esté disponible o el dispositivo de salida no dé soporte a gráficos. Para algunos informes, en los que necesita números exactos, los informes numéricos como por ejemplo tablas y matrices son más adecuados. Para obtener detalles sobre Performance Reporter for MVS o Tivoli Decision Support for OS/390, consulte la publicación Performance Reporter for OS/390, System Performance Feature Reference, Volume 2. RMF Resource Management Facility (RMF) recopila datos de todo el sistema que describen la actividad del procesador (tiempo de ESPERA), la actividad de E/S (uso de canal y dispositivo), actividad del almacenamiento principal (estadísticas de paginación de conmutación y demanda) y actividad (carga de trabajo) del gestor de recursos del sistema (SRM). RMF Versión 4 es una herramienta de medición centralizada que supervisa la actividad del sistema para recopilar datos de planificación de capacidad y rendimiento. El análisis de los informes de RMF proporciona la base para ajustar el sistema a los requisitos del usuario. También pueden realizar un seguimiento del uso de los recursos. RMF Versión 4 realiza una medición de las actividades siguientes: v Uso del procesador v Uso del espacio de direcciones v Actividad de canal: – Tasa de solicitudes y tiempo de servicio por canal físico – Relaciones de canal lógico a canal físico – Profundidad de cola de canal lógico y razones de la colocación en cola. v Actividad y contención de dispositivo para los dispositivos siguientes: – Registro de unidad – Gráficos – Almacenamiento de acceso directo – Equipo de comunicación – Cintas magnéticas – Lectores de caracteres. v Paginación detallada del sistema v Carga de trabajo detallada del sistema v Conjunto de datos de página y conmutación v Colocación en cola. RMF Versión 4 permite al usuario de z/OS: v Evaluar la capacidad de respuesta del sistema: – Identificar los cuellos de botella – El informe de paginación detallado asociado con la actividad de página y conjunto de datos de conmutación pueden proporciona una buena imagen del comportamiento de un entorno de almacenamiento virtual. Capítulo 13. Análisis del rendimiento 391 Medición del rendimiento v Comprobar los efectos de los ajustes: – Los resultados se pueden observar dinámicamente en una pantalla o mediante los recursos posteriores al proceso. v Realizar evaluación de planificación de capacidad: – Los informes de la actividad de carga de trabajo incluyen el servicio del intervalo desglosado por los elementos principales como procesador, entrada/salida y servicio de almacenamiento principal. – El análisis de la salida del supervisor de recursos (por ejemplo, los indicadores de contención del sistema, el intercambio desglosado por categoría, promedio de usuarios preparados por dominio) ayuda a comprender los entornos de usuario y a realizar previsión de tendencias. – Las funciones posteriores al proceso facilitan el análisis de periodos de carga de hora punta y el análisis de tendencias. v Gestionar las mayores cargas de trabajo y los mayores recursos a los que z/OS puede dar soporte. v Identificar y medir el uso de las vías de acceso de canal en línea. v Optimizar la utilidad de la capacidad de almacenamiento ampliado. RMF mide e informa sobre la actividad del sistema y, en la mayoría de los casos, utiliza una técnica de muestreo para recopilar los datos. Los informes se pueden realizar con uno de los tres supervisores siguientes: 1. El Supervisor I realiza mediciones y notifica sobre el uso de recursos del sistema (es decir, el procesador, los dispositivos de E/S, almacenamiento y conjuntos de datos en los que un trabajo se puede poner en cola durante su ejecución). Se ejecuta en segundo plano y realiza mediciones de los datos durante un periodo de tiempo. Los informes se pueden imprimir inmediatamente después de la finalización del intervalo de medición, o bien los datos se pueden almacenar en registros de SMF e imprimir posteriormente con el postprocesador de RMF. El postprocesador de RMF se puede utilizar para generar informes para excepciones: condiciones donde se han superado los valores especificados por el usuario. 2. El Supervisor II, como el Supervisor I, realiza mediciones y notifica sobre el uso de los recursos del sistema. Se ejecuta en segundo plano en TSO o en una consola. Proporciona informes de instantánea sobre el uso de los recursos y también permite que los datos se almacenen en registros de SMF. El postprocesador de RMF se puede utilizar para generar informes de excepciones. 3. El Supervisor III principalmente realiza mediciones de la contención de los recursos del sistema y del retardo de los trabajos que causa esta contención. Recopila y notifica los datos en tiempo real en una estación de pantalla, con copia de seguridad impresa opcional de visualizaciones individuales. El Supervisor III también proporciona informes de excepciones, pero sus datos no se pueden almacenar en registros de SMF. RMF debe estar activo en el sistema 24 horas al día. Ejecútelo con una prioridad de asignación superior a la de los otros espacios de direcciones en el sistema, de forma que: v Los informes se graben con el intervalo solicitado v Otro trabajo no sufra retardos debido a los bloqueos mantenidos por RMF. Se genera un informe en el intervalo de tiempo especificado por la instalación. La sobrecarga más grande del sistema de RMF se produce durante la generación de informes: cuando menor sea el intervalo entre informes, mayor será la carga sobre 392 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Medición del rendimiento el sistema. Se recomienda un intervalo de 60 minutos para la operación normal. Cuando esté tratando un problema específico, reduzca el intervalo de tiempo a 10 ó 15 minutos. Los registros de RMF se pueden dirigir a los conjuntos de datos de SMF con las opciones NOREPORT y RECORD; no se produce sobrecarga de informes y los registros de SMF se pueden formatear posteriormente. Para obtener detalles sobre RMF Versión 4, consulte las publicaciones MVS/ESA Resource Measurement Facility (RMF) Version 4 Program Summary y MVS/ESA Resource Measurement Facility (RMF) General Information. ACF/VTAM ACF/VTAM (número de programa 5735-RC2) proporciona información sobre el uso del almacenamiento intermedio a GTF en datos de rastreo de SMF o a una consola del sistema mediante los mandatos DISPLAY y BFRUSE. Otras estadísticas de ajuste también se pueden registrar en la consola del sistema mediante el mandato MODIFY nombre_proc, TNSTAT. (Este mandato se describe en la publicación ACF/VTAM Diagnostic Techniques.) VSAM VSAM LISTCAT proporciona información que interpreta la situación real de los conjuntos de datos de VSAM. Esta información incluye recuentos de: v Si se producen divisiones del intervalo de control (CI) o del área de control (CA), y con qué frecuencia (las divisiones se deberían producen muy raramente). v Accesos físicos al conjunto de datos. v Extensiones de un conjunto de datos (asignación secundaria). Evite esta asignación secundaria, si es posible, haciendo que la asignación primaria sea lo suficientemente grande. v Niveles de índice. Datos de rendimiento de Tivoli Workload Scheduler for z/OS Puede recibir automáticamente información de rendimiento de IBM Tivoli Workload Scheduler for z/OS utilizando la palabra clave STATMSG de la sentencia de inicialización JTOPTS. Se da soporte a tres valores para STATMSG: CPLOCK La subtarea de gestor de sucesos emite los mensajes EQQE004 y EQQE005, que describen la frecuencia con la que las distintas tareas hacen referencia al conjunto de datos del plan actual. La colocación en cola SYSZDRK/nombre_ssCP la toman las subtareas que acceden al plan actual. En la mayoría de los casos, la colocación en cola se toma de forma exclusiva. Sólo la subtarea de servicio general, que maneja solicitudes de usuarios de diálogos del host, PIF, la API, pone en cola respecto al recurso compartido. Se espera cierto grado de contención sobre el recurso, ya que las subtareas continuamente toman el bloqueo, procesan trabajo y liberan el bloqueo. Si hay contención de recurso durante más del 50% del tiempo durante un intervalo del que se ha realizado la medición, revise las recomendaciones de ajuste. IBM Tivoli Workload Scheduler for z/OS emite estos mensajes cuando el número de sucesos que ha procesado es superior a aproximadamente la mitad del valor de la palabra clave BACKUP. Si ha especificado BACKUP(NO), IBM Tivoli Workload Scheduler for z/OS utiliza el valor predeterminado de la palabra clave BACKUP (400) para calcular cuándo emitir mensajes a CPLOCK. El Capítulo 13. Análisis del rendimiento 393 Medición del rendimiento número de sucesos procesados incluye todos los sucesos que procesa IBM Tivoli Workload Scheduler for z/OS y no sólo los sucesos para operaciones del plan actual. EVENTS La subtarea de gestor de sucesos emite los mensajes EQQE000I, EQQE006I y EQQE007I, que describen cuántos sucesos se han procesado y proporcionan estadísticas para los distintos tipos de sucesos. IBM Tivoli Workload Scheduler for z/OS emite estos mensajes cuando el número de sucesos que ha procesado es superior a aproximadamente la mitad del valor de la palabra clave BACKUP. Si ha especificado BACKUP(NO), IBM Tivoli Workload Scheduler for z/OS utiliza el valor predeterminado de la palabra clave BACKUP (400) para calcular cuándo emitir mensajes para EVENTS. El número de sucesos procesados incluye todos los sucesos que procesa IBM Tivoli Workload Scheduler for z/OS y no sólo los sucesos para operaciones del plan actual. WSATASK La tarea de gestor de sucesos emite los mensajes EQQE008I y EQQE009I, que describen la información de estadística recopilada por la tarea de WSA. Todos estos mensajes se emiten según los criterios siguientes: v Si STATIM se ha establecido en un valor distinto de 0 (especificando STATIM(n) en la palabra clave JTOPTS, o utilizando el mandato de modificación /F subsys,STATIM=n), el mensaje se emite aproximadamente cada n minutos, si se ha procesado algún suceso. v De lo contrario, si EVELIM se ha establecido en un valor distinto de cero (especificando EVELIM(n) en la palabra clave JTOPTS, o utilizando el mandato de modificación /F subsys,EVELIM=n), el mensaje se emite aproximadamente cada n sucesos. v De lo contrario, el mensaje se emite aproximadamente cada n sucesos, donde n es la mitad del valor de la palabra clave JTOPTS BACKUP (el valor predeterminado de BACKUP es 400). GENSERV La subtarea de servicio general emite los mensajes EQQG010 a EQQG011, que describen la frecuencia con la que se han procesado los distintos tipos de solicitud y la longitud que ha tenido la cola de servicio general. IBM Tivoli Workload Scheduler for z/OS emite estos mensajes cada 30 minutos si se han procesado solicitudes. La información de rendimiento de la subtarea de JCC se puede obtener de la salida de archivado de SYSOUT (EQQUX005). 394 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Capítulo 14. Actividades básicas de ajuste En este capítulo se describen los recursos del sistema y se proporcionan algunos ajustes básicos para los administradores, programadores e ingenieros de sistemas de IBM Tivoli Workload Scheduler for z/OS para mejorar el rendimiento del entorno de IBM Tivoli Workload Scheduler for z/OS. En general, si tiene un soporte para carga de trabajo de producción grande controlado por IBM Tivoli Workload Scheduler for z/OS, más de 5000 operaciones de sistemas por día, considere los requisitos de rendimiento de IBM Tivoli Workload Scheduler for z/OS como lo haría para cualquier aplicación de software de sistemas grandes. Recursos del sistema Al igual que cualquier otra aplicación, IBM Tivoli Workload Scheduler for z/OS utiliza recursos para realizar el trabajo que se desea. En esta sección se presentan los recursos principales y se describen las ramificaciones en el rendimiento de cada uno de ellos en relación a una carga de trabajo interactiva del producto IBM Tivoli Workload Scheduler for z/OS. Los recursos principales son hora de E/S, procesador y almacenamiento. Existe una correlación directa entre la disponibilidad de almacenamiento real, la disponibilidad de almacenamiento virtual, la actividad de E/S y la utilización del procesador. Si se agota el almacenamiento real o virtual, se produce un aumento de la actividad de E/S, que a su vez produce un aumento de la utilización del procesador. Por lo tanto, un cambio en cualquiera de estas áreas tiene cierto efecto en la utilización de los demás recursos. Actividad de E/S Las operaciones de entrada/salida son normalmente el factor más significativo de cualquier ecuación de rendimiento. Una reducción de E/S, ya sea real o física, a menudo genera los beneficios más significativos en cualquier ejercicio de ajustes. Hay disponibles muchas técnicas para eliminar E/S y para conseguir un rendimiento óptimo para la E/S física. Algunas de estas técnicas se describen en esta publicación. Si tiene una carga de trabajo muy alta, considere las opciones de mejora de rendimiento, ya sean de hardware o software, que tiene disponibles. Sin embargo, le recomendamos que no utilice software que altere la organización física de un conjunto de datos, ya que esto puede afectar negativamente a la disponibilidad y los datos de IBM Tivoli Workload Scheduler for z/OS. El número de E/S reales se puede reducir eliminando procesos innecesarios y modificando las definiciones de clúster de VSAM. El rendimiento de las E/S físicas se puede optimizar mediante la utilización de recursos de hardware de DASD. La duración de una E/S física es muy dependiente del rendimiento del subsistema de E/S, que está considerablemente influenciado por la cuidadosa colocación de los datos para reducir la contención de canal, vía de acceso y unidad de control. © Copyright IBM Corp. 1991, 2011 395 Recursos del sistema Eliminación de procesos innecesarios En esta sección se describen las funciones de IBM Tivoli Workload Scheduler for z/OS que pueden causar muchos procesos innecesarios, con ningún beneficio o escasos beneficios, cuando no se utilizan de la forma que se espera. v Alertas, específicamente ALERT(LATEOPER), cuando las fechas límite y las duraciones estimadas de las operaciones no son precisas. Esto puede causar un gran número de E/S para un plan actual y afecta a la mayoría de las otras funciones de IBM Tivoli Workload Scheduler for z/OS ya que el bloqueo del plan actual se mantiene exclusivamente durante la duración de la exploración de operaciones con retardo. La subtarea del analizador de la estación de trabajo (WSA) realiza esta exploración cada dos minutos. Cuando un porcentaje alto del plan tiene retardo, se deben recuperar muchos registros de operaciones. v Un entorno de seguridad definido inadecuadamente. Las definiciones de AUTHDEF de subrecursos que no tienen reglas hacen que se envíen FRACHECK a través de la interfaz de SAF sólo para que básicamente el sistema de seguridad los ignore. Asegúrese de definir sólo nombres de subrecursos en la sentencia AUTHDEF para las que realmente existen reglas de recursos. v Copias de seguridad demasiado frecuentes del plan actual o del repositorio de JCL. Las copias de seguridad de CP se realizan probablemente con demasiada frecuencia si hay más de una cada 20 minutos durante el periodo de hora punta de proceso. La mayoría de las instalaciones no requieren más de una copia de seguridad de repositorio de JCL por día. Si no se puede encontrar un valor óptimo para las palabras clave BACKUP o MAXJSFILE para conseguir la frecuencia de copia de seguridad necesaria, considere definir NO como valor y planificar las copias de seguridad utilizando el mandato BACKUP, EQQEVPGM, EQQUSIN o la subrutina EQQUSINB. v Exploración innecesaria de todos los JCL enviados. Si utiliza los recursos de adaptación de entrada proporcionados por IBM Tivoli Workload Scheduler for z/OS, asegúrese de utilizar VARSUB(SCAN) en lugar de VARSUB(YES) en la sentencia de inicialización OPCOPTS si el rendimiento es importante y menos del 70% de las operaciones enviadas tienen entrada adaptada por IBM Tivoli Workload Scheduler for z/OS en el momento del envío. v No utilice la función de comprobación de terminación de trabajo (JCC) para restablecer códigos de retorno aceptables distintos de cero. La sentencia de inicialización NOERROR es una alternativa mucho más eficaz y mucho más segura. De forma adicional, z/OS proporciona funciones para fallar un trabajo con un error de JCL en la terminación del paso si se detecta una condición no catalogada x, eliminando de esta forma la necesidad de utilizar JCC para detectar este tipo de condiciones. v Funciones de auditoría. AUDIT con AMOUNT(DATA) produce un aumento importante de E/S y una cantidad considerable de espacio de DASD en los registros de seguimiento de trabajos. Si el propio registro cambiado no es necesario, considere realizar la auditoría con AMOUNT(KEY). Se da soporte a múltiples sentencias de auditoría, lo que permite de esta forma definir algunos archivos con AMOUNT(DATA) y otros con AMOUNT(KEY). v Considere el almacenamiento de GETMAINing y FREEMAINing para salidas de usuario en EQQUX000, la salida de inicio/detención del subsistema, en lugar de obtener y liberar en cada llamada. v Retarde la recuperación de los registros de trabajos hasta que un usuario del diálogo haya solicitado examinar un registro de trabajos para comprobador de seguimiento no z/OS. 396 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Recursos del sistema Capítulo 15, “Ajuste del controlador y del rastreador”, en la página 403 contiene recomendaciones adicionales más específicas del comprobador de seguimiento o del controlador, muchas de las cuales también dan como resultado la eliminación de procesos innecesarios. Definiciones de clústeres de VSAM Las bases de datos y planes de IBM Tivoli Workload Scheduler for z/OS se almacenan en clústeres KSDS de VSAM. Las definiciones de clústeres predeterminadas proporcionadas con IBM Tivoli Workload Scheduler for z/OS no consideran el rendimiento de E/S a los clústeres. Mientras que los cambios de las definiciones de clústeres pueden proporcionan mejoras de rendimiento significativas, los cambios de este tipo causan un uso de almacenamiento adicional por parte del espacio de direcciones del controlador o un aumento de espacio de DASD. Considere estas recomendaciones de rendimiento: v Utilice las opciones IMBED y REPLICATE si los clústeres no están detrás de la MEMORIA CACHÉ. IMBED especifica que el registro de establecimiento de secuencia para cada área de control se graba tantas veces como el tamaño lo permita en la primera pista adyacente al área de control. Si la asignación es inferior a un cilindro, se añade una pista a las cantidades de asignación primaria y secundaria. REPLICATE especifica que cada registro de índice se grabará en una pista tantas veces como el tamaño lo permita. Con REPLICATE, se reduce el retardo rotativo y se aumenta el rendimiento. Pero el índice del clúster normalmente requiere más espacio de dispositivo de acceso directo. | | | | | | | | | | | | | | | | | | | | | | | | | | | v Defina cierto espacio libre en los clústeres que tengan una actividad de inserción significativa, especialmente el repositorio de JCL (EQQJS1DS y EQQJS2DS), que requiere como mínimo FREESPACE(20, 20). Considere una asignación de espacio libre para el plan actual (EQQCP1DS, EQQCP2DS, EQQCXDS, EQQNCPDS y EQQSCPDS), datos ampliados (EQQXD1DS, EQQXD2DS y EQQNXDDS), descripciones de las aplicaciones (EQQADDS), descripciones de los recursos (EQQRDDS) e instrumentos del operador (EQQOIDS). FREESPACE(porcentaje-CI, porcentaje-CA) especifica el porcentaje de cada intervalo de control y área de control que se va a reservar como espacio libre cuando el clúster se cargue inicialmente, durante una inserción masiva y después de cualquier división de intervalos de control (porcentaje-CI) y áreas de control (porcentaje-CA). El espacio vacío del intervalo de control y del área de control está disponible para registros de datos que se actualizan e insertan después de que el clúster se haya cargado localmente. porcentaje-CI convierte el número de bytes que es igual o ligeramente inferior al valor de porcentaje de porcentaje-CI. porcentaje-CA se convierte en un número de intervalos de control que es igual a o ligeramente inferior al valor de porcentaje de porcentaje-CA. porcentaje-CI y porcentaje-CA deben ser igual o inferior a 100. Cuando especifica FREESPACE(100 100), se coloca un registro de datos en cada intervalo de control utilizado para datos y un intervalo de control en cada área de control utilizada para datos (es decir, un registro de datos se almacena en cada área de control cuando se carga el conjunto de datos). Cuando no hay ningún valor FREESPACE codificado, el valor predeterminado especifica que no se reservará espacio libre cuando se cargue el conjunto de datos. Cuando define el clúster utilizando el parámetro RECORDS, la cantidad de espacio libre especificada no se tiene en cuenta en los cálculos para determinar la asignación primaria. Capítulo 14. Actividades básicas de ajuste 397 Recursos del sistema v Asigne más almacenamientos intermedios en los clústeres que no tienen almacenamiento intermedio de LSR. BUFFERSPACE especifica el espacio mínimo que se proporcionará para los almacenamientos intermedios. El tamaño del espacio de almacenamiento intermedio que especifica ayuda a VSAM a determinar el tamaño del intervalo de control del componente de índice y del componente de datos. Si BUFFERSPACE no está codificado, VSAM intenta obtener espacio suficiente para contener dos intervalos de control del componente de datos y un intervalo de control del componente de índice. Intente tener un solo almacenamiento intermedio para cada CA de índice, además de uno adicional. v Si no requiere el soporte DISTRIBUIDO, no asigne el clúster con el atributo de distribución. De manera predeterminada, EQQADDS, EQQLTDS y EQQLDDS son clústeres distribuidos. DISTRIBUIDO especifica que si la longitud máxima de un registro de datos (tal y como se especifica con RECORDSIZE) es mayor que un intervalo de control, el registro está contenido en más de un intervalo de control. Esto permite a VSAM seleccionar un tamaño de intervalo de control que sea óptimo para el dispositivo de acceso directo. Cuando un registro de datos con un tamaño mayor que un intervalo de control se coloca en un clúster que permite registros distribuidos, la primera parte del registro llena completamente un intervalo de control. Los intervalos de control subsiguientes se rellenan hasta que el registro se graba en el clúster. El espacio inutilizado en el último intervalo de control del registro no está disponible para contener otros registros de datos. La distribución de un clúster hace que el número de E/S físicas aumente drásticamente. Si debe definir un clúster con un atributo de distribución y el rendimiento es importante, considere utilizar CACHE y DASD-FAST-WRITE para estos clústeres. v Especifique como mínimo AMP=(’BUFND=5,BUFNI=5’) en el procedimiento de JCL de IBM Tivoli Workload Scheduler for z/OS para el controlador en los ddnames EQQCPxDS y EQQJSxDS. Las copias de CP y JS son NSR, se ejecutan más rápidamente con almacenamientos intermedios adicionales. Colocación de conjuntos de datos Coloque los principales conjuntos de datos de IBM Tivoli Workload Scheduler for z/OS en volúmenes que minimicen la contención para los volúmenes en sus controladores. Considere cuidadosamente la colocación de estos conjuntos de datos críticos de rendimiento: v Conjuntos de datos del plan actual (EQQCP1DS, EQQCP2DS y EQQCXDS) v Información complementaria del plan actual (EQQSIDS) v Conjuntos de datos de suceso (EQQEVDS) v Conjuntos de datos de envío/liberación (EQQSUDS) v Repositorio de JCL (EQQJS1DS y EQQJS2DS) v Registros de seguimiento de trabajos (EQQJTnn y EQQJTARC) v Tablas de variables de JCL cuando se utiliza la adaptación de entrada de trabajos (EQQADDS). Opciones de rendimiento de hardware Utilice CACHE y DASD-FAST-WRITE si puede para los archivos que se recomienda a continuación. Aunque estos recursos no reducen el número de EXCP, pueden reducir drásticamente el tiempo que se tarda en completarlos. CACHE y DASD-FAST-WRITE pueden ser maneras importantes de reducir la contención de colocación en cola por dos motivos. En primer lugar, DASD-FAST-WRITE puede 398 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Recursos del sistema reducir los tiempos de grabación. La colocación en el almacenamiento intermedio, por supuesto, sólo reduce los tiempos de lectura, y eso puede hacer que la reducción de los tiempos de grabación sea incluso más importante. En segundo lugar, tanto CACHE como DASD-FAST-WRITE son eficaces en registros distribuidos. CACHE Adecuado para todos los archivos a excepción de los registros de seguimiento de trabajos. Los mejores candidatos son los siguientes: v El plan a largo plazo (EQQLTDS) v Instrucciones del operador (EQQOIDS) v Descripciones de las aplicaciones y tablas de variables de JCL (EQQADDS) v Las bibliotecas de JCL (EQQJBLIB) v Conjuntos de datos de suceso (EQQEVDS), pero sólo cuando se ha iniciado una tarea de lector de suceso utilizando la palabra clave ERDRTASK del parámetro de inicialización OPCOPTS. DASD-FAST-WRITE Adecuado para todos loa archivos. Los mejores candidatos son los siguientes: v Los registros de seguimiento de trabajos (EQQJTnn) v Conjuntos de datos de envío/liberación (EQQSUDS) v El repositorio de JCL (EQQJS1DS y EQQJS2DS) v Conjuntos de datos de suceso (EQQEVDS) v Conjuntos de datos del plan actual (EQQCP1DS y EQQCP2DS). Si envía un número muy alto de operaciones de sistema cada día (mayor que 50.000) y tiene dispositivos de estado sólido, considere colocar el repositorio de JCL (EQQJS1DS y EQQJS2DS) y los conjuntos de datos de envío/liberación (EQQSUDS) en estos dispositivos. Procesador Normalmente, la cantidad de potencia del procesador no es el factor más significativo del rendimiento de IBM Tivoli Workload Scheduler for z/OS. Por supuesto, independientemente de la potencia del procesador, si el procesador en su mayor parte está normalmente ocupado, éste puede ser el recurso más crítico de la aplicación. En este caso, puede ayudar a IBM Tivoli Workload Scheduler for z/OS a acceder al recurso del procesador proporcionándole mayor prioridad de asignación. Es posible que esto no tenga un efecto significativo sobre los usuarios con prioridad más baja, ya que en la mayoría de los casos IBM Tivoli Workload Scheduler for z/OS requiere el procesador con frecuencia, pero no lo necesita mucho. Los subsistemas IBM Tivoli Workload Scheduler for z/OS deben tener una prioridad inmediatamente por debajo de la del subsistema JES. Almacenamiento del procesador Es normal cierta cantidad de paginación e intercambio para sistemas que dan servicio a muchos usuarios, o que tienen una cantidad considerable de datos en el almacenamiento virtual. El efecto en el rendimiento del sistema de esta actividad normalmente no es grave. Las pocas operaciones de E/S adicionales por Capítulo 14. Actividades básicas de ajuste 399 Recursos del sistema transacción para paginación e intercambio no implican normalmente un aumento significativo de la E/S que sería necesaria sin la paginación y el intercambio. Si el rendimiento es importante, defina los espacios de direcciones de IBM Tivoli Workload Scheduler for z/OS como no intercambiables. El almacenamiento virtual de un procesador puede superar considerablemente el tamaño del almacenamiento central disponible en la configuración. Cualquier exceso se debe mantener en el almacenamiento auxiliar (DASD) o en el almacenamiento ampliado. Este almacenamiento virtual se produce en bloques de direcciones denominados páginas. Sólo las páginas de almacenamiento virtual a las que se ha hecho referencia más recientemente se asignan para ocupar bloques de almacenamiento central físico. Cuando hace referencia a una página de almacenamiento virtual que no está actualmente en el almacenamiento central, la página se trae desde DASD o el almacenamiento ampliado para sustituir a una página en el almacenamiento central que no esté en uso y que se haya utilizado menos recientemente. Se dice que la nueva página a la que se ha hecho referencia se ha transferido. Es posible que la página desplazada deba ser reenviada si ha cambiado. IBM Tivoli Workload Scheduler for z/OS utiliza una cantidad considerable de almacenamiento virtual, tanto en el espacio de direcciones del controlador como por parte de los programas por lotes que crean los planes actuales. La técnica de colocación en el almacenamiento intermedio de los recursos compartidos locales (LSR) la utiliza IBM Tivoli Workload Scheduler for z/OS para el conjunto de datos del plan actual; un porcentaje del plan actual determinado por la palabra clave CPDTLIM en la sentencia OPCOPTS se mantiene en los almacenamientos intermedios de LSR por encima de la línea de 16 MB. Estos almacenamientos intermedios de LSR se suprimen y se vuelven a crear cada vez que se realiza una copia de seguridad del plan actual, para asegurar que el porcentaje del plan que desea está siempre en el almacenamiento. El espacio de direcciones del controlador también crea y mantiene dos espacios de datos, uno para calendarios y uno para recursos especiales. El tamaño del espacio de datos de calendario depende del número de calendarios definidos. El espacio de datos de recursos especiales contiene todos los recursos especiales a los que se hace referencia en el plan actual. Los espacios de datos los amplía automáticamente IBM Tivoli Workload Scheduler for z/OS para acomodar datos adicionales. Problemas de paginación La velocidad de transferencia de páginas es de gran importancia, ya que la actividad de transferencia de páginas se produce de forma síncrona (es decir, una tarea de z/OS se detiene hasta que se resuelve el error de la página). La actividad de reenvío de páginas se solapa con el proceso de IBM Tivoli Workload Scheduler for z/OS, de forma que no afecta de forma significativa al rendimiento. Una transferencia de página desde el almacenamiento expandido implica sólo un pequeño coste de uso de procesador, pero una transferencia de página desde DASD implica un coste de tiempo para la E/S física y un aumento más considerable de uso de procesador. Por lo tanto, la actividad adicional de transferencia de página desde DASD ralentiza la velocidad a la que controlador procesa las transacciones. Si sospecha que un problema de rendimiento está relacionado con paginación excesiva, puede utilizar RMF para obtener las velocidades de paginación. 400 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Indicadores de problemas relacionados con el rendimiento Indicadores de problemas relacionados con el rendimiento Los siguientes indicadores externos pueden identificar problemas relacionados con el rendimiento: v Larga cola de operaciones del sistema en estado R sin estado ampliado y sin razón indicada en el panel EQQSOPSP. v Retardo considerable entre cuando un trabajo finaliza y la hora a la que IBM Tivoli Workload Scheduler for z/OS notifica el resultado satisfactorio o anómalo de la operación. Este retardo se puede medir como la diferencia entre la hora de creación del suceso en el registro de sucesos y la hora de la entrada del registro de seguimiento de trabajos asociado. El programa de auditoría de IBM Tivoli Workload Scheduler for z/OS lista la hora de creación y la hora de proceso del controlador de los sucesos. De forma adicional, tanto Performance Reporter for z/OS and Tivoli Decision support for OS/390 incluyen tablas para calcular el retardo de proceso de sucesos. Consulte las recomendaciones del capítulo siguiente para tratar problemas más específicos relacionados con el rendimiento en el envío de problemas, proceso de sucesos y comunicación de sucesos. Cómo evitar cuellos de botella Puede evitar los problemas relacionados con el rendimiento si examina periódicamente la información que puede identificar los posibles problemas. Considere realizar las tareas siguientes a intervalos regulares: v Examen de las estadísticas de IBM Tivoli Workload Scheduler for z/OS generadas cuando la palabra clave STATMSG está definida en la sentencia de inicialización OPCOPTS. v Reorganizaciones periódicas de los clústeres de VSAM: EQQADDS, EQQRDDS, EQQSIDS y EQQOIDS. v Supervisar la salida de IDCAMS LISTCAT de los clústeres de VSAM para asegurar una asignación óptima. Incremente la asignación de espacio libre si se producen con frecuencia divisiones de CI y CA. Vuelva a asignar el clúster con una asignación primaria grande, si tiene extensiones. v Revisar el registro de mensajes (EQQMLOG) para identificar cuándo se realizan copias de seguridad de CP y JS, y con qué frecuencia. v Formar a la comunidad de usuarios acerca de cómo pueden evitar solicitudes de diálogos de larga ejecución: – Promover la utilización de las opciones de FASTPATH, cuando estén disponibles. – Utilizar caracteres genéricos de búsqueda sólo cuando sea necesario. Especifique la máxima información posible para limitar la búsqueda. – Familiarizar a los usuarios con la estructura principal de los clústeres de VSAM. Intente crear criterios de selección de diálogos teniendo en cuenta la clave para evitar búsquedas secuenciales de los clústeres. Capítulo 14. Actividades básicas de ajuste 401 Cómo evitar cuellos de botella 402 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Capítulo 15. Ajuste del controlador y del rastreador Este capítulo le ayuda a identificar actividades de ajuste adecuadas para tratar problemas de rendimiento generales y específicos relacionados con el controlador y el comprobador de seguimiento. Asegúrese de revisar las recomendaciones de Capítulo 14, “Actividades básicas de ajuste”, en la página 395 antes de implementar las recomendaciones de este capítulo. Ajuste del controlador Los problemas de rendimiento en el controlador a menudo están asociados con la colocación en cola del plan actual. La cantidad de tiempo que las subtareas mantienen el bloqueo está directamente relacionado con la cantidad de trabajo que las subtareas deben realizar. IBM Tivoli Workload Scheduler for z/OS genera mensajes que documentan el uso del bloqueo del plan actual cuando se define STATMSG(CPLOCK) en la sentencia de inicialización de JTOPTS. Las subtareas que utilizan el bloqueo del plan actual son las siguientes: v La subtarea del analizador de la estación de trabajo (WSA) para iniciar operaciones en estaciones de trabajo de sistema, WTO y no de informe. El WSA también genera alertas cuando se define LATEOPER o DURATION en la sentencia de inicialización ALERTS. v La subtarea del gestor de sucesos (EM) procesa los sucesos enviados desde los comprobadores de seguimiento y actualiza el plan actual según corresponda. El gestor de sucesos también actúa en nombre de las funciones de reinicio y limpieza (RC), recuperación automática (AJR) y seguimiento de sucesos (ETT). v Las subtareas de servicio general (GS) proporcionan la interfaz entre los datos del controlador y el usuario. Proporciona servicio a los usuarios de diálogos de ISPF y OS/2, programas de transacción de la API y la interfaz de programa. GS es el único usuario de bloqueo del plan actual que puede tomar control del bloqueo compartido, para verdaderas transacciones de solo lectura. v La subtarea del gestor de modalidad normal (NMM) es responsable de la integridad de los datos del controlador. NMM pone en cola el bloqueo de CP cuando son necesarias copias de seguridad del plan actual o del repositorio de JCL, o cuando se ha creado un nuevo plan actual (NCP). Envío de trabajos Esta sección le ayuda a comprender el proceso de envío de trabajos e identifica las actividades de ajuste. Cómo reconocer los indicadores Estos elementos identifican un cuello de botella en el envío de trabajos: v STATMSG(CPLOCK) identifica un tiempo de retención (HOLD) largo para el WSA. v STATMSG(CPLOCK) identifica un tiempo de espera (WAIT) largo para el EMGR, NMM y GS cuando se compara con el WSA. v Una cola larga de operaciones en estado R sin estado ampliado y sin motivo documentado en el panel EQQSOPSP. © Copyright IBM Corp. 1991, 2011 403 Ajuste del controlador Desglose del proceso Para enviar un trabajo, IBM Tivoli Workload Scheduler for z/OS debe hacer lo siguiente: v Identificar al mejor candidato. Una vez que se ha obtenido el bloqueo del plan actual, las operaciones preparadas se ordenan según su prioridad relativa. El valor de la palabra clave QUEUELEN de JTOPTS identifica el número máximo de operaciones preparadas que utilizará el WSA cada vez que se ponga en cola en el bloqueo del plan actual. v Recuperar JCL: – Influenciado por el número de PDS y el número de miembros en el conjunto de datos concatenado en el ddname EQQJBLIB. Si los PDS se encuentran detrás de la memoria CACHÉ, la búsqueda de directorios es más rápida. – Tamaño de los miembros de EQQJBLIB. – El rendimiento de las salidas de usuario EQQUX001, EQQUX002, EQQUX009 y EQQUX013. v Sustituir y adaptar JCL. v Crear una imagen de la entrada del trabajo en el archivo de repositorio de JCL (JS). La duración de este paso depende del rendimiento de VSAM en el repositorio de JCL. v Enviar a un lector interno. Esta función la realiza la subtarea de enviar, que no mantiene el bloqueo del plan actual. De esta forma, el rendimiento en el lector interno no puede afectar a las demás subtareas de IBM Tivoli Workload Scheduler for z/OS. Sin embargo, puede afectar en última instancia al rendimiento del trabajo en el procesador. Recomendaciones Considere las recomendaciones siguientes: v Utilice la salida EQQUX002 para localizar el JCL en casos en los que hay muchas bibliotecas concatenadas en EQQJBLIB y la biblioteca de destino es predecible, quizás según el nombre de la estación de trabajo, o nombre de trabajo, por ejemplo. v Concatene sólo bibliotecas que interesen a IBM Tivoli Workload Scheduler for z/OS en EQQJBLIB. Asegúrese de que las bibliotecas se concatenan en orden de frecuencia. Es decir, si más del 50% del JCL se almacena en una biblioteca, esa biblioteca debe ser la primera concatenada en EQQJBLIB. Si hay recursos disponibles, mantenga los directorios de estas bibliotecas en el almacenamiento. v La definición de FREESPACE en el repositorio de JCL (EQQJS1DS y EQQJS2DS) es esencial. v Examine el rendimiento de EQQUX001, EQQUX002 y EQQUX013, si se utilizan. El bloqueo del plan actual se mantiene mientras se invocan las tres salidas, el rendimiento es crítico. v Utilice VARSUB(SCAN) en lugar de VARSUB(YES) cuando se requiera adaptación de JCL. v Si a menudo hay muchas operaciones preparadas para iniciarse, considere establecer un valor QUEUELEN más alto. Una vez que el WSA tiene el bloqueo, los envíos se manejan muy rápidamente. Un sistema correctamente ajustado puede enviar decenas de operaciones por segundo. v Examine el rendimiento de JES, especialmente en el conjunto de datos de punto de comprobación, ya que esto afecta en gran medida el tiempo de envío del lector interno. 404 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Ajuste del controlador Seguimiento de trabajos Esta sección le ayuda a comprender los factores que afectan al rendimiento del gestor de sucesos e identifica las acciones para ocuparse de estos factores. La subtarea del gestor de sucesos es con frecuencia víctima de un bajo rendimiento por parte de otros usuarios del bloqueo del plan actual, raramente es la causa. Cómo reconocer los indicadores Los indicadores siguientes pueden resaltar los problemas de rendimiento en la subtarea del gestor de sucesos: v STATMSG(CPLOCK) identifica un tiempo de retención (HOLD) largo para el EMGR. v STATMSG(CPLOCK) identifica un tiempo de espera (WAIT) largo para el WSA, NMM, o GS cuando se compara con EMGR. v Largo retardo desde la creación del suceso al proceso del suceso. Compare la hora de creación en el registro de sucesos con la hora de registro del registro de seguimiento de trabajos. Performance Reporter for MVS, Tivoli Decision Support for OS/390 y EPDM proporcionan tablas para notificar retardo de sucesos; el programa de auditoría de IBM Tivoli Workload Scheduler for z/OS lista las horas de creación y las horas de proceso del controlador de los sucesos. v Número total de sucesos recibidos por el gestor de sucesos comparado con los que realmente son de interés para IBM Tivoli Workload Scheduler for z/OS. v Número inusualmente alto de sucesos suspendidos, identificados mediante un 2 en la columna 53 del registro de seguimiento de trabajos. También puede identificar sucesos suspendidos localizando SUSPENDED en el informe generado por el paquete de auditoría de IBM Tivoli Workload Scheduler for z/OS. v Salidas de usuario implicadas en el seguimiento, EQQUX007 y en EQQUX004, EQQUX005 y EQQUX006 del comprobador de seguimiento. El método de conexión y el rendimiento del comprobador de seguimiento son también indicadores. Recomendaciones Considere las recomendaciones siguientes: v Reduzca el número de sucesos suspendidos disminuyendo el tiempo ERWAIT. v Ajuste los comprobadores de seguimiento. v Elimine el mayor número posible de sucesos triviales: – Utilice STEPEVENTS(ABEND) o STEPEVENTS(NZERO) en lugar de STEPEVENTS(ALL). – Especifique PRINTEVENTS(NO) si no realiza seguimiento de operaciones de impresión. – Filtre la carga de trabajo de prueba utilizando EQQUX004. – Filtre los sucesos de tipo 5, a excepción de aquellos con EXROPCAN, si la impresión no es de interés. v Utilice las conexiones NCF o XCF en lugar de iniciar lectores de sucesos. Cuando utilice NCF o XCF para las comunicaciones, asegúrese de utilizar la opción EWSEQNO en la sentencia de inicialización EWTROPTS. El inicio de una tarea de lector de sucesos específica en el comprobador de seguimiento no es necesario y reduce drásticamente la E/S al conjunto de datos de suceso y, lo que tiene mayor importancia, la longitud de la vía de acceso de un suceso para llegar al controlador. Capítulo 15. Ajuste del controlador y del rastreador 405 Ajuste del controlador v Asegúrese de que el rendimiento de EQQUX007 sea correcto, si se utiliza. El bloqueo del plan actual se mantiene cuando se toma la salida. Respuesta del diálogo Esta sección le ayuda a comprender los factores que afectan al rendimiento de la subtarea de servicio general e identifica las acciones para tratar estos factores. Factores que influencian los tiempos de respuesta Considere los factores siguientes: v El número de operaciones del plan y el tamaño de las redes. El plan actual consta de redes de apariciones. Las apariciones con operaciones dependientes se insertan en la misma red. En muchas instalaciones, el tamaño de la red de mayor tamaño puede ser de hasta un 80% de todo el plan. Cuando la tarea de servicio general procesa una solicitud de modificación, por ejemplo, para añadir una aparición con dependencias, IBM Tivoli Workload Scheduler for z/OS debe asegurarse de que el cambio no causa un bucle en la red. v Tipos de solicitudes específicos que inician exploraciones de red. Por ejemplo, la modificación de una dependencia en un diálogo MCP. v Construcción inadecuada de solicitudes de lista que dan como resultado búsquedas secuenciales del conjunto de datos del plan actual. v Tiempo utilizado para buscar en la concatenación ISPxLIB paneles, mensajes y módulos de carga. Recomendaciones Considere las recomendaciones siguientes: v Utilice GSTASK(5), el valor máximo para aumentar el paralelismo para solicitudes de diálogos. v Utilice FASTPATH=Y para búsquedas de tablas de nombres de trabajos en los paneles 6.3 y 5.3. v Seleccione atravesar la red para ver si hay bucles de dependencia sólo cuando el cambio se almacene, en lugar de hacerlo en el panel donde define la dependencia. Además, cuando el cambio se almacene y se modifiquen las dependencias externas en el plan actual, utilice DEP CHECK=N en los paneles de dependencias MCP para eliminar la exploración de red de ese panel. v Considere la utilización de LIBDEF para las asignaciones de ISPF si hay varias bibliotecas ya concatenadas en ISPxLIB. v Considere mover EQQMINOJ, EQQXDSPX y EQQXTBLX a una biblioteca LPA. Estos módulos los cargan los usuarios del diálogo cada vez que especifican una opción del menú principal de IBM Tivoli Workload Scheduler for z/OS. v Determine cuándo utilizar y cuándo no utilizar genéricos, y evite utilizar caracteres genéricos en la primera posición de un campo. Estudie la estructura principal de los registros del plan actual. v Elimine la mayor parte de la supervisión activa de las operaciones del plan actual utilizando las funciones de alertas automáticas proporcionadas por IBM Tivoli Workload Scheduler for z/OS. Proceso por lotes en segundo plano Esta sección le ayuda a comprender los factores que afectan al rendimiento del proceso por lotes en segundo plano e identifica las acciones para tratar estos factores. 406 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Proceso por lotes en segundo plano Cómo reconocer los indicadores De la misma forma que con cualquier proceso por lotes, un rendimiento incorrecto se indica mediante: v Velocidad de E/S alta y tiempo de CPU relativamente bajo v Excesivo tiempo transcurrido v Velocidades de paginación de alta demanda, especialmente durante la planificación diario. Recomendaciones Considere las recomendaciones siguientes: v Utilice bloqueo de media pista tanto como sea posible v Añada almacenamientos intermedios de VSAM mediante sentencias AMP de JCL para clústeres que no se procesan utilizando la técnica de colocación en almacenamiento intermedio de LSR. v Considere la utilización de LSR por lotes en EQQADDS, EQQWSDS y EQQRDDS para proceso por lotes de planificación diaria y a largo plazo. v Realice ajustes generales de z/OS: examine las velocidades de intercambio, las prioridades de asignación, el UIC y especialmente las velocidades de paginación de demanda. Reduzca la paginación de demanda, si es posible, o considere mover los trabajos por lotes de planificación diario a un procesador con más almacenamiento real, en el mismo anillo de GRS que el controlador, si hay uno disponible. Ajuste del rastreador Esta sección le ayuda a identificar las actividades de ajuste adecuadas para tratar problemas generales y específicos de rendimiento relacionados con el comprobador de seguimiento. Creación y comunicación de sucesos Los retardos son raramente obvios en el espacio de direcciones del comprobador de seguimiento. En su lugar, a menudo se producen problemas con el Gestor de sucesos. Estos elementos pueden indicar problemas de rendimiento: v El mensaje EQQZ035 mientras se inicia el espacio de direcciones. Esto indica que se han perdido sucesos debido a que la cola de grabador de sucesos en ECSA se ha llenado con sucesos sin procesar. v Margen significativo entre la hora de creación registrada en el registro de sucesos y la hora de creación del registro de seguimiento de trabajos para el mismo suceso. v Cola larga de JCC, normalmente mostrada por SDSF. Factores que afectan al rendimiento El rendimiento del comprobador de seguimiento resulta afectado por lo siguiente: v El número de sucesos generados en el sistema. v La longitud de los registros lógicos del conjunto de datos de suceso (EQQEVDS) cuando se utiliza la función de reinicio y limpieza. v El tamaño de los registros de trabajos cuando se utiliza JCC o la función de reinicio y limpieza. v Una subtarea de lector de sucesos específica iniciada utilizando ERDRTASK(1) en lugar de EWSEQNO (Event Data Set Sequence Number) en EWTROPTS. Cuando se inicia una subtarea de lector de sucesos específica, los sucesos los Capítulo 15. Ajuste del controlador y del rastreador 407 Ajuste del rastreador graba en el conjunto de datos de suceso la subtarea de grabador de sucesos y a continuación inmediatamente los lee de vuelta la tarea del lector de sucesos. Si el método de conexión es XCF, NCF, o el controlador y el comprobador de seguimiento se han iniciado en el mismo espacio de direcciones, utilice en su lugar EWSEQNO (Event Data Set Sequence Number). Cuando utiliza EWSEQNO (Event Data Set Sequence Number), los sucesos se colocan en cola en la subtarea responsable de la comunicación con el gestor de sucesos al mismo tiempo que se graban en el conjunto de datos de suceso. v El valor definido por ERWAIT, cuando se utilizan subtareas de lector de sucesos, identifica el tiempo que espera la subtarea a volver a comprobar el conjunto de datos de suceso si no se ha encontrado ningún suceso nuevo en el último intento. v Rendimiento de las salidas de usuario EQQUX004, EQQUX005, EQQUX006, EQQUX008 y EQQUX010. v El rendimiento de JES cuando se ha iniciado JCC o se utiliza la función de reinicio y limpieza para recuperar registros de trabajos. Recomendaciones Considere las recomendaciones siguientes: v No utilice STEPEVENTS(ALL) a menos que utilice la función de recuperación automática y esté interesado en si un paso se ha desechado. v No especifique PRINTEVENTS(YES) a menos que esté interesado en realizar un seguimiento de las operaciones de impresión, o inhabilite IEFU83 para sucesos de impresión si JES2. v Filtre la carga de trabajo de prueba utilizando EQQUX004. v Considere filtrar los sucesos de tipo 5, a excepción de aquellos con EXROPCAN activado, si no especifica PRTCOMPLETE(YES). v Asegúrese de que haya suficiente ECSA definido para que la cola del grabador de sucesos pueda manejar el proceso en hora punta, y la reserva de hardware ocasional. v No gestione con HSM el conjunto de datos de suceso, no coloque el conjunto de datos de suceso en un volumen donde realice copias de seguridad de todo el volumen. v Consulte la publicación Installation Guide para ver recomendaciones sobre el cálculo de la longitud de los registros lógicos del conjunto de datos de suceso cuando se utilice la función de reinicio y limpieza. v Examine las recomendaciones de ajustes de JCC y de reinicio y limpieza. JCC Cuando se utiliza la función de JCC, el resultado satisfactorio o anómalo de una operación no lo puede determinar el controlador hasta que la tarea de JCC ha procesado la salida en la agrupación de JES. JCC comprueba cada línea de SYSOUT respecto a tablas que definen las condiciones que se deben detectar. Medición del rendimiento de JCC Puede realizar mediciones del rendimiento de JCC haciendo lo siguiente: v Utilizando la salida EQQUX005. Indicadores de llamada específicos indican cuándo se ha invocado la salida para empezar a procesar un nuevo trabajo y cuándo no hay más salida para comprobar para un trabajo. El buen rendimiento de la salida es vital ya que se invoca para cada línea de SYSOUT a menos que indique a IBM Tivoli Workload Scheduler for z/OS que detenga la invocación. 408 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Ajuste del rastreador v Observa la cola de salida utilizando SDSF. Mientras se está comprobando, el trabajo aparece resaltado en la cola. El rendimiento en JCC resulta afectado principalmente por el rendimiento de JES y también por el tamaño de los registros de trabajos. Recomendaciones Considere las recomendaciones siguientes: v Si actualmente direcciona toda la salida para el proceso de JCC a un solo sistema de la configuración, considere comprobar la salida en el sistema donde se ha ejecutado el trabajo para equilibrar la carga de trabajo de JCC entre los procesadores disponibles. La tarea de JCC no puede procesar varios trabajos en paralelo. v Elimine el proceso de JCC innecesario: – Detección de códigos de retorno distintos de cero, utilice NOERROR en su lugar. – Condición de excepción NOT CATLG x, utilice z/OS para fallar el trabajo cuando finalice el paso. – OMITA secciones de la salida donde no pueda de ninguna forma correlacionar una condición definida en las tablas de mensajes. – Evite la exploración de los conjuntos de datos de SYSOUT de usuario, si es posible. Reinicio y limpieza Cuando se utiliza la función de reinicio y limpieza, el rendimiento de IBM Tivoli Workload Scheduler for z/OS se reduce si hay un gran número de solicitudes para archivado y recuperación de SYSOUT de usuario. Capítulo 15. Ajuste del controlador y del rastreador 409 Reinicio y limpieza 410 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Apéndice A. Vectores de alertas genéricas de NetView IBM Tivoli Workload Scheduler for z/OS da soporte a la transmisión de una alerta genérica a NetView, utilizando la interfaz de programa a programa (PPI) de NetView. La acción se solicita mediante la palabra clave GENALERTS de la sentencia de inicialización ALERTS. Una alerta genérica sigue un formato SNA predefinido. Se transporta en un transporte de vectores de gestión de red (NMVT). Un NMVT consta de varios subvectores, cada uno de los cuales transporta un tipo de datos específico. Todas las alertas de IBM Tivoli Workload Scheduler for z/OS contienen el subvector de ID de conjunto del producto, el subvector de tiempo y como mínimo uno de los subvectores de usuario, instalación o anomalía. En las tablas siguientes se describe cada uno de los tipos de alertas. Los subvectores del ID de conjunto del producto y de tiempo son comunes a todas las alertas, de forma que no se incluyen en las descripciones siguientes. Consulte la publicación SNA Formats para obtener más información sobre la arquitectura de alertas genéricas. Alerta de subsistema anómalo El subsistema IBM Tivoli Workload Scheduler for z/OS ha terminado sin haber sido detenido por un operador. Un terminación anómala en el subsistema se ha filtrado hasta la rutina ESTAE de la tarea superior de IBM Tivoli Workload Scheduler for z/OS, EQQMAJOR, o se ha producido un terminación anómala en EQQMAJOR. Tabla 42. Alerta de subsistema anómalo Subvector Punto de código Número de ID de alerta X'C82EBCBF' Tipo de alerta X'01' Pérdida permanente de recurso Descripción de la alerta X'2000' Un programa de software ha terminado de forma anómala Causas probables X'1000' Programa de software Causas de la anomalía X'10A0' X'82'SF: X'C9' Subsistema de software © Copyright IBM Corp. 1991, 2011 Texto NAME 411 Alerta de subsistema anómalo Tabla 42. Alerta de subsistema anómalo (continuación) Subvector Punto de código Texto Acciones X'00A1' X'82'SFs: X'B3' X'B4' X'01A8' X'82'SF: X'B5' X'141F' X'3303' X'10AC' X'82'SFs: X'B3' X'B4' X'B5' X'30E1' X'83'SF Revise REGISTRO DE MENSAJES REGISTRO DEL SISTEMA OPERATIVO Verifique que ___ se ha creado VOLCADO Reinicie el subsistema de software Si el resultado no es satisfactorio, haga lo siguiente Guarde REGISTRO DE MENSAJES REGISTRO DEL SISTEMA OPERATIVO VOLCADO PÓNGASE EN CONTACTO CON EL REPRESENTANTE DE SERVICIO DE IBM Tivoli Workload Scheduler for z/OS Alerta de subtarea anómala Una subtarea de IBM Tivoli Workload Scheduler for z/OS ha finalizado de forma inesperada. Tabla 43. Alerta de subtarea anómala Subvector Punto de código Número de ID de alerta X'BC705A72' Tipo de alerta X'01' Pérdida permanente de recurso Descripción de la alerta X'2000' Un programa de software ha terminado de forma anómala Causas probables X'1000' Programa de software Causa de la anomalía X'10BF' X'82'SF: X'C9' Subtarea de software X'00A1' X'82'SFs: X'B3' X'B4' X'01A8' X'82'SF: X'B5' X'141F' X'3303' X'10AC' X'82'SFs: X'B3' X'B4' X'B5' X'30E1' X'83'SF Revise Acciones 412 Texto NOMBRE REGISTRO DE MENSAJES REGISTRO DEL SISTEMA OPERATIVO Verifique que ___ se ha creado VOLCADO Reinicie la subtarea de software Si el resultado no es satisfactorio, haga lo siguiente Guarde REGISTRO DE MENSAJES REGISTRO DEL SISTEMA OPERATIVO VOLCADO PÓNGASE EN CONTACTO CON EL REPRESENTANTE DE SERVICIO DE IBM Tivoli Workload Scheduler for z/OS IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Alerta de operación con error Alerta de operación con error Una operación en IBM Tivoli Workload Scheduler for z/OS ha finalizado con error. Tabla 44. Alerta de operación con error Subvector Punto de código Texto Número de ID de alerta X'CFC0DD60' Tipo de alerta X'01' Pérdida permanente de disponibilidad Descripción de la alerta X'2000' Un programa de software ha terminado de forma anómala Causas probables X'1001' Programa de aplicación Causa de la anomalía X'1001' Programa de aplicación Acciones X'1000' X'2000' Realice procedimientos de recuperación de problemas Revise los datos detallados Subvectores adicionales X'98' X'82’SFs' X'DF'SF X'BB'SF X'BD'SF X'BC'SF X'DD'SF X'BF'SF X'12'SF X'CA'SF X'C2'SF Datos detallados ID de la estación de trabajo Número de operación Hora de llegada de entrada de la operación Prioridad de la operación Nombre de la aplicación Hora de llegada de entrada de la aplicación Código de error de software Nombre del trabajo Número de trabajo Alerta de operación con retraso Un operación de IBM Tivoli Workload Scheduler for z/OS va con retraso. La operación ha llegado a su última hora de inicio pero no se ha iniciado aún. Tabla 45. Alerta de operación con retraso Subvector Punto de código Texto Número de ID de alerta X'956BCEFC' Tipo de alerta X'12' Gravedad desconocida Descripción de la alerta X'210A' Operación de software no iniciada Causas probables X'1001' Programa de aplicación Causa de la anomalía X'1001' Programa de aplicación Acciones X'1000' X'2000' Realice procedimientos de recuperación de problemas Revise los datos detallados Subvectores adicionales X'98' X'DF'SF X'BB'SF X'BD'SF X'BC'SF X'DD'SF X'BF'SF Datos detallados ID de la estación de trabajo Número de operación Hora de llegada de entrada de la operación Prioridad de la operación Nombre de la aplicación Hora de llegada de entrada de la aplicación Apéndice A. Vectores de alertas genéricas de NetView 413 Alerta de larga duración Alerta de larga duración Una operación de IBM Tivoli Workload Scheduler for z/OS ha estado activa un tiempo demasiado largo (superior a su duración estimada, multiplicada por el límite de información, dividido entre 100). Si el límite de información se establece en 0, la operación ha estado activa más tiempo que su duración estimada. Tabla 46. Alerta de larga duración Subvector Punto de código Texto Número de ID de alerta X'9EC7E374' Tipo de alerta X'12' Gravedad desconocida Descripción de la alerta X'210B' Un programa de software no termina Causas probables X'1001' Programa de aplicación Causa de la anomalía X'1001' Programa de aplicación Acciones X'1000' X'2000' Realice procedimientos de recuperación de problemas Revise los datos detallados Subvectores adicionales X'98' X'DF'SF X'BB'SF X'BD'SF X'BC'SF X'DD'SF X'BF'SF X'CA'SF X'C2'SF Datos detallados ID de la estación de trabajo Número de operación Hora de llegada de entrada de la operación Prioridad de la operación Nombre de la aplicación Hora de llegada de entrada de la aplicación Nombre del trabajo Número de trabajo Alerta de umbral de cola excedido Una cola de IBM Tivoli Workload Scheduler for z/OS ha excedido un valor de umbral. A excepción de la cola del grabador de sucesos, los valores de umbral son múltiplos de 10 entre 10% y 90% y a continuación 95% y 99%. IBM Tivoli Workload Scheduler for z/OS comprueba el tamaño de una cola cuando se añade un suceso a ella. Si una cola se llena, IBM Tivoli Workload Scheduler for z/OS termina de forma anómala. Además de la cola del grabador de sucesos, las colas de subtarea de IBM Tivoli Workload Scheduler for z/OS pueden contener hasta 32.000 sucesos. La cola del grabador de sucesos no se maneja de la misma forma que las colas de subtarea de IBM Tivoli Workload Scheduler for z/OS. El tamaño de la cola del grabador de sucesos lo determina la cantidad de ECSA que asigna. La cola se comprueba cada vez que el grabador de sucesos va a leer sucesos; la acción de alerta se realiza cuando la cola supera el 50%. Si se llena la cola del grabador de sucesos, se emite un mensaje que indica cuántos sucesos se han perdido, pero IBM Tivoli Workload Scheduler for z/OS no finaliza. Tabla 47. Alerta de umbral de cola excedido Subvector Punto de código Número de ID de alerta X'222DCE5C' Tipo de alerta X'11' Problema latente detectado en recurso Descripción de la alerta X'2000' Un programa de software ha terminado de forma anómala 414 Texto IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Alerta de umbral de cola excedido Tabla 47. Alerta de umbral de cola excedido (continuación) Subvector Punto de código Texto Causas probables X'1000' Programa de software Causa de la anomalía X'F0C4' X'82'SFs: X'00' X'B5' ____ porcentaje de ____ en uso X'00A1' X'82'SF: X'B3' X'0171' Revise Acciones ' ' (en primer espacio en blanco) QUEUE (en segundo espacio en blanco) REGISTRO DE MENSAJES Compruebe la contención del sistema Apéndice A. Vectores de alertas genéricas de NetView 415 Alerta de umbral de cola excedido 416 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Apéndice B. Macros de Tivoli Workload Scheduler for z/OS Las macros que se identifican en este apéndice las proporciona IBM Tivoli Workload Scheduler for z/OS como interfaces de programación para los clientes. Atención: No utilice macros de IBM Tivoli Workload Scheduler for z/OS como interfaces de programación distintas de las que se identifican en este apéndice. IBM Tivoli Workload Scheduler for z/OS proporciona las macros siguientes que son interfaces de programación: EQQCASEC La macro de definición de lista de códigos de caso crea listas de códigos de caso en el módulo de definición de códigos de caso (EQQCASEM). Este módulo lo utiliza la función de recuperación automática. Para obtener más información, consulte “Creación de módulos de definición de código de caso” en la página 346. EQQJCCT La macro de tabla de mensajes de JCC crea definiciones de tablas de mensajes para la comprobación de terminación de trabajo. En “Definición de tablas de mensajes utilizando EQQJCCT” en la página 320 se describe la macro. © Copyright IBM Corp. 1991, 2011 417 418 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Apéndice C. Biblioteca de ejemplos (SEQQSAMP) La biblioteca SEQQSAMP contiene ejemplos para ayudarle a instalar, migrar y personalizar Tivoli Workload Scheduler for z/OS. En la mayoría de los casos, sólo necesita añadir JCL específico de la instalación para adaptar un miembro de SEQQSAMP a sus requisitos. En la Tabla 48 se muestran los miembros de la biblioteca de ejemplos que puede utilizar para personalizar o ajustar Tivoli Workload Scheduler for z/OS. En las páginas siguientes se describen estos miembros más detalladamente. Para obtener una lista de todos los miembros de la biblioteca SEQQSAMP, consulte la publicación Installation Guide. Si necesita cambiar un miembro de ejemplo, copie el origen en una biblioteca distinta. A continuación, el miembro de ejemplo original estará disponible para su consulta. Además, cree un SMP/E usermod para cada miembro de ejemplo que ejecute en el entorno de producción. Los cambios al código fuente de ejemplo se indicarán con un distintivo para distinguirlos, y las actualizaciones posteriores se reflejarán en el código de producción lo antes posible. Tabla 48. Miembros de la biblioteca SEQQSAMP para personalización y ajuste de Tivoli Workload Scheduler for z/OS Miembro Breve descripción EQQAIXST Parámetros utilizados por los ejemplos EQQX9AIX y EQQAIXTR. EQQAIXTR comprobador de seguimiento de ejemplo en ejecución en AIX, utilizado con EQQX9AIX. EQQAUDIB Ejemplo para invocar EQQAUDIT en modalidad de proceso por lotes fuera del diálogo. Nota: EQQAUDIB se puede utilizar satisfactoriamente sólo si los campos de dsn de salida EQQAUDIT y dsnname EQQTROUT del panel EQQJOBSA panel se han rellenado. EQQBENCR JCL de EQQE2EPW de ejemplo para ejecutar el programa de utilidad que cifra las contraseñas de Windows definidas con el parámetro USRPSW de la sentencia USRREC. EQQCHKEV JCL de ejemplo para visualizar la información del contenido del conjunto de datos de suceso EQQTWSIN y EQQTWSOU. EQQCLEAN Procedimiento de ejemplo que invoca el programa EQQCLEAN. EQQCONOP Parámetros iniciales de ejemplo para un controlador y rastreador en el mismo espacio de direcciones. EQQCONO Procedimiento de tarea iniciada de ejemplo sólo para controlador. EQQCONP Parámetros iniciales de ejemplo para un controlador. EQQCON Procedimiento de tarea iniciada de ejemplo para un controlador y rastreador en el mismo espacio de direcciones. EQQCVM Ejemplo para habilitar los recursos de seguimiento de trabajos en sistemas VM. EQQCVM2 Ejemplo para habilitar el envío y seguimiento en sistemas VM utilizando EQQUX009. EQQDBENC Contiene el JCL para cifrar la contraseña en la sentencia DBOPT EQQDBOPT Sentencia DBOPT de ejemplo EQQDELDI JCL de ejemplo para ejecutar el programa EQQDELDS que suprime conjuntos de datos en función de la disposición especificada en el JCL y el estado actual en el catálogo. EQQDLFX Ejemplo de instalación de ensamblador de salida de conexión/desconexión de DLF. EQQDPX01 Salida de usuario de ejemplo por lotes de DP para actualizar el entorno de planificación 2.4.1. EQQDSCL Ejemplo de limpieza por lotes. EQQDSCLP Parámetros de ejemplo de limpieza por lotes. © Copyright IBM Corp. 1991, 2011 419 Biblioteca de ejemplos (SEQQSAMP) Tabla 48. Miembros de la biblioteca SEQQSAMP para personalización y ajuste de Tivoli Workload Scheduler for z/OS (continuación) Miembro Breve descripción EQQDSEX Ejemplo de exportación por lotes. EQQDSEXP Parámetros de ejemplo de exportación por lotes. EQQDSIM Ejemplo de importación por lotes. EQQDSIMP Parámetros de ejemplo de importación por lotes. EQQDSRG rreorg de ejemplo por lotes. EQQDSRI Índice de recuperación por lotes. EQQDSRIP Parámetros de índice de recuperación por lotes. EQQDSTP Parámetros de procedimiento de ejemplo para iniciar almacén de datos. EQQDST Procedimiento de ejemplo para iniciar almacén de datos. EQQE2EP Parámetros iniciales de ejemplo para servidor y proceso por lotes para definir cuándo está activa la planificación global con capacidades de tolerancia a errores. EQQFLWAT JCL de ejemplo para invocar el programa de utilidad filewatch para supervisar los cambios de los archivos HFS o ZFS. EQQICNVH Trabajo de ejemplo para migrar tablas de DB2 de historial. EQQJCCTB JCL para ensamblar una definición de macro de tabla de mensajes de JCC. EQQJCLIN JCL de ejemplo para iniciar el programa EQQPDLF. EQQJVXIT Salida de sustitución de variables de JCL de ensamblador de ejemplo. También se utiliza para variables en mandatos de automatización del sistema. EQQMTWSO JCL de ejemplo para migrar la longitud de registro de conjunto de datos EQQTWSOU de 120 a 160 bytes. EQQNCFCT Parámetros de ejemplo para una conexión SNA entre controlador y rastreador. EQQNETW1 REXX EXEC que recibe mensajes WTO de IBM Tivoli Workload Scheduler for z/OS y emite mandatos de MVS. EQQNETW2 Procesador de mandatos de PL/I NetView que utiliza EQQUSINT para cambiar el estado de las operaciones. EQQNETW3 REXX EXEC que utiliza EQQEVPGM para cambiar el estado de las operaciones. EQQOS2ST Parámetros utilizados por los ejemplos EQQX9OS2 y EQQOS2TR. EQQOS2TR comprobador de seguimiento de ejemplo en ejecución en OS/2, utilizado por EQQX9OS2. EQQPCS04 Asigna VSAM para almacén de datos EQQPCS05 Asigna el directorio de trabajos (WRKDIR) utilizado por un servidor para las características de planificación global con tolerancia a errores. EQQPCS06 Asigna Tivoli Workload Scheduler for z/OS y Tivoli Workload Scheduler Integration. EQQPCS07 Asigna conjuntos de datos de VSAM de reinicio y limpieza. EQQPIFJX Ejemplo para mantener el repositorio de JCL. EQQPROC Procedimiento de ejemplo, iniciado por Tivoli Workload Scheduler for z/OS, para iniciar la depuración de objetos de DLF. EQQRETWT Terminación anómala de terminación/espera de ejemplo o programa de RC. EQQSERP Parámetros iniciales de ejemplo para un servidor. EQQSER Procedimiento de tarea iniciada de ejemplo para un servidor. EQQSLCHK Ejemplo para realizar una comprobación sintáctica en miembros de la biblioteca de SCRIPTS. EQQTCPCT Definiciones de ejemplo para la comunicación TCP/IP entre rastreador y controlador. 420 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Biblioteca de ejemplos (SEQQSAMP) Tabla 48. Miembros de la biblioteca SEQQSAMP para personalización y ajuste de Tivoli Workload Scheduler for z/OS (continuación) Miembro Breve descripción EQQTRAP Parámetros iniciales de ejemplo para un comprobador de seguimiento. EQQTRA Procedimiento de tarea iniciada de ejemplo para un comprobador de seguimiento. EQQTROPT Sentencia TRGOPT de ejemplo EQQXML01 Archivo XML de ejemplo para definiciones de reglas de sucesos desencadenantes de conjunto de datos EQQUSIN1 Ejemplo de subrutina EQQUSIN para cambiar el estado de una operación. EQQUSIN2 Ejemplo de subrutina EQQUSIN para cambiar la disponibilidad de un recurso especial. EQQUSIN3 Ejemplo de subrutina EQQUSIN para cambiar el estado de una estación de trabajo. EQQUSIN4 Ejemplo de subrutina EQQUSIN para realizar copia de seguridad de un conjunto de datos de recursos de Tivoli Workload Scheduler for z/OS. EQQUSIN5 Ejemplo de subrutina EQQUSIN para actualizar el campo USERDATA de una operación. EQQUX001 Salida de envío de trabajo de ejemplo. EQQUX002 Salida de lectura de biblioteca de trabajos de ejemplo. EQQUX003 Salida de información de descripción de la aplicación de ejemplo. EQQUX004 Salida de filtrado de sucesos de ejemplo. EQQUX011 Salida de grabación de registro de seguimiento de trabajos de ejemplo. EQQUX013 Salida de prevención de adaptación de trabajos de ejemplo. EQQUX014 Salida de operación dependiente del tiempo de ejemplo EQQUX0N Salida de detención/inicio de PL/I de ejemplo, EQQUX000. EQQUX9N salida de iniciación de operación de PL/I de ejemplo, en comunicación con VM (EQQUX009). EQQUXCAT Ejemplo de salida de catálogo de EQQDELDS/EQQCLEAN. Se puede utilizar para impedir la supresión de conjuntos de datos específicos. EQQUXGDG Ejemplo de salida de EQQCLEAN que impide la ejecución de cualquier acción de sobrescritura de GDG en bloques de control de JES. EQQUXPIF Ejemplo de validación de descripción de la aplicación. EQQVTAMN controlador/comprobador de seguimiento de VTAM/NCF de ejemplo. EQQVTAMS Definición de VTAM/APPC de ejemplo para un servidor de Tivoli Workload Scheduler for z/OS. EQQX5ASM Salida de archivado de SYSOUT de ejemplo. EQQX6ASM Salida de creación de registro de incidencia de ejemplo. EQQX6JOB JCL de esqueleto de trabajos por lotes de ejemplo utilizado por EQQX6ASM. EQQX7ASM Salida de cambio de estado de ejemplo. EQQX7JOB JCL de esqueleto de trabajos de ejemplo utilizado por EQQX7ASM. EQQX9AIX salida de iniciación de operación de ensamblador de ejemplo, en comunicación con AIX. EQQX9OS2 Salida de iniciación de operación de ensamblador de ejemplo, en comunicación con OS/2. EQQXCFCT Definiciones de ejemplo para la conexión XCF entre rastreador y controlador. Ejemplos de EQQUSIN SEQQSAMP contiene ejemplos que muestran cómo utilizar la subrutina general, EQQUSIN. Puede utilizar EQQUSIN en lugar de las subrutinas individuales EQQUSINB, EQQUSINO, EQQUSINS, EQQUSINT y EQQUSINW. Proporciona funciones adicionales que no están disponibles en las subrutinas individuales. Los Apéndice C. Biblioteca de ejemplos (SEQQSAMP) 421 Ejemplos de EQQUSIN parámetros se pasan a EQQUSIN en un almacenamiento intermedio APP, que tiene el mismo formato que los almacenamientos intermedios utilizados por la interfaz de programación de aplicaciones (API) de IBM Tivoli Workload Scheduler for z/OS. Pero es necesario invocar los servicios APPC para utilizar EQQUSIN. Se proporcionan los siguientes ejemplos de EQQUSIN: EQQUSIN1 Es un ejemplo para cambiar el estado de una operación del plan actual. Es equivalente a la utilización de EQQUSINT. EQQUSIN2 Es un ejemplo para cambiar la disponibilidad de un recurso especial. Es equivalente a la utilización de EQQUSINS. Pero EQQUSIN también permite especificar valores de cantidad, desviación y creación, que no están disponibles mediante EQQUSINS. EQQUSIN3 Es un ejemplo para cambiar el estado de una estación de trabajo. Es equivalente a la utilización de EQQUSINW. EQQUSIN4 Es un ejemplo para realizar una copia de seguridad de un conjunto de datos de recursos de IBM Tivoli Workload Scheduler for z/OS. Es equivalente a la utilización de EQQUSINB. EQQUSIN5 Es un ejemplo para actualizar el campo USERDATA de una operación del plan actual. Es equivalente a la utilización de EQQUSINO. Salidas de Tivoli Workload Scheduler for z/OS Las salidas de ejemplo demuestran implementaciones prácticas pero es posible que necesite actualizarlas para adaptarlas a sus necesidades. Puede utilizar los ejemplos que se proporcionan como base para sus salidas. Cuando se inicia Tivoli Workload Scheduler for z/OS, éste intenta, de manera predeterminada, cargar las salidas con el prefijo EQQUX0. Puede cambiar los valores predeterminados especificando parámetros en la sentencia de inicialización EXITS. Consulte “EXITS” en la página 62 para obtener más información sobre la sentencia EXITS. Salida de inicio o detención IBM Tivoli Workload Scheduler for z/OS invoca la salida de inicio o detención cuando se inicia el subsistema, comprobador de seguimiento o controlador y también durante una conclusión normal. La salida se utiliza normalmente para asignar recursos necesarios por otras salidas de IBM Tivoli Workload Scheduler for z/OS. El miembro EQQUX0N de SEQQSAMP contiene una salida de inicio/detención de ejemplo escrita en PL/I. Este ejemplo invoca la subrutina EQQUSINW para variar el estado de una estación de trabajo definida por el usuario en ACTIVA. El ejemplo se ha diseñado específicamente para ser utilizado con los ejemplos EQQCVM2 y EQQUX9N que proporcionan un comprobador de seguimiento para un sistema operativo VM, pero se puede utilizar para establecer el estado de cualquier estación de trabajo definida por el usuario. Consulte “Rastreador para VM” en la página 427 para obtener más información sobre el comprobador de seguimiento de VM. 422 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Salidas Salida de envío de trabajo Se invoca la salida de envío de trabajo cuando IBM Tivoli Workload Scheduler for z/OS va a enviar un trabajo por lotes o iniciar una tarea iniciada. Una utilización común de esta salida es asignar un ID de usuario de envío. Si no modifica el ID de usuario de envío, todos los trabajos enviados por IBM Tivoli Workload Scheduler for z/OS, de manera predeterminada, se realizan con el ID de usuario del espacio de direcciones de IBM Tivoli Workload Scheduler for z/OS que realiza el envío. La seguridad a menudo se realiza mediante el campo RUSER, pero puede utilizar también esta salida para crear una tarjeta LOGONID si los estándares de instalación lo requieren. Puede determinar el usuario de envío a partir de una serie de fuentes. Incluyen las siguientes: v Nombre de trabajo especificado en el JCL v Información de contabilidad de trabajos v Campo del nombre del programador v ID de propietario de la aparición v ID de grupo de autorización de la aparición. El miembro EQQUX001 de SEQQSAMP contiene una salida de envío de trabajo de ejemplo. Este ejemplo asigna un ID de usuario específico en función del nombre de trabajo definido en la operación. Salida de lectura de biblioteca de trabajos Se invoca la salida de lectura de biblioteca de trabajos cuando IBM Tivoli Workload Scheduler for z/OS no puede encontrar el JCL de un trabajo en el conjunto de datos de repositorio de JCL (EQQJSnDS). De manera predeterminada, IBM Tivoli Workload Scheduler for z/OS busca la concatenación de los conjuntos de datos asignados al ddname EQQJBLIB en el procedimiento de JCL del controlador. Si desea que IBM Tivoli Workload Scheduler for z/OS busque en otros conjuntos de datos, instale EQQUX002 para realizar esta función. La asignación dinámica de JCL resulta muy útil si la instalación funciona como un departamento de servicios de sistemas para diversos clientes o departamentos independientes. Cuando las bibliotecas de trabajos independientes están concatenadas en la sentencia EQQJBLIB, pueden aparecer nombres de miembros duplicados en distintos conjuntos de datos de la biblioteca de trabajos. Colocando JCL en bibliotecas de trabajos distintas y a continuación utilizando EQQUX002 para asignar dinámicamente una biblioteca para una aplicación determinada, puede proteger más fácilmente el JCL de cada cliente. Considere también la utilización de EQQUX002 para mejorar el rendimiento si tiene muchos conjuntos de datos particionados (PDS) grandes concatenados a EQQJBLIB. Para encontrar un miembro en el último conjunto de datos de la concatenación, IBM Tivoli Workload Scheduler for z/OS debe leer el directorio de todos los PDS precedentes, lo que puede presentar una sobrecarga significativa. Considere la definición de un PDS y un ddname correspondiente para cada estación de trabajo de sistema. A continuación, EQQUX002 puede buscar en una biblioteca específica. Si no se encuentra ningún JCL, puede permitir que IBM Tivoli Workload Scheduler for z/OS busque en la concatenación de EQQJBLIB el JCL. El miembro EQQUX002 de SEQQSAMP contiene una salida de lectura de biblioteca de trabajos de ejemplo. Este ejemplo busca un ddname MYJOBLIB antes de EQQJBLIB. Apéndice C. Biblioteca de ejemplos (SEQQSAMP) 423 Salidas Salida de filtrado de sucesos Se invoca la salida de filtrado de sucesos cuando un grabador de sucesos de IBM Tivoli Workload Scheduler for z/OS va a grabar un suceso en el conjunto de datos de suceso o, en los casos en los que se utilice EWSEQNO, añadir el suceso a una cola XCF o NCF. En esta salida, puede seleccionar entre descartar sucesos creados por las salidas de JES y SMF o indicar que un suceso que se colocaría normalmente en cola en JCC no es procesado por JCC. EQQUX004 se utiliza normalmente para filtrar los sucesos creados por trabajo no de producción. Si ejecuta un número considerable de trabajos de prueba y otro trabajo, y los estándares de denominación de trabajos le permiten hacerlo, considere utilizar EQQUX004 para filtrar el trabajo no de producción. El miembro EQQUX004 de SEQQSAMP contiene una salida de filtrado de sucesos de ejemplo que incluye o excluye sucesos en función del nombre de trabajo. Salida de archivado de SYSOUT La salida de archivado de SYSOUT, EQQUX005, la invoca la comprobación de terminación de trabajo durante el proceso de conjuntos de datos de SYSOUT para un trabajo. Se puede invocar la salida varias veces para el mismo trabajo conforme JCC avanza por los distintos conjuntos de datos de SYSOUT. Esta salida se utiliza normalmente para cambiar la disposición SYSOUT definida, en función del resultado satisfactorio o anómalo del trabajo. Tenga en cuenta que EQQUX005 es una salida del comprobador de seguimiento, aunque el resultado satisfactorio o anómalo de una operación lo determina en última instancia el controlador. El miembro EQQX5ASM de SEQQSAMP contiene una salida de archivado de SYSOUT de ejemplo. Este ejemplo vuelve a colocar en cola SYSOUT para trabajos anómalos en una clase distinta de la que se utiliza para los trabajos satisfactorios. Resulta útil si desea imprimir el JCL de los trabajos anómalos para los operadores de recuperación de trabajos. SYSOUT para trabajos que se completan satisfactoriamente se puede grabar en una clase de salida gestionada por un grabador del sistema. Salida de creación de registro de incidencia La salida EQQUX006 la invoca la comprobación de terminación de trabajo para crear un registro de incidencia cuando una tabla de mensajes de JCC especifica que se debe crear un registro de incidencia. El ejemplo EQQUX006 proporcionado por IBM Tivoli Workload Scheduler for z/OS genera registros de incidencias en un solo formato. Sin embargo, puede crear su propio formato sustituyendo la salida de ejemplo por su propia versión. El miembro EQQX6ASM de SEQQSAMP contiene una salida de creación de registro de incidencia de ejemplo. Esta salida la invoca el grabador de archivos de incidencias de JCC para crear uno o varios registros que se pueden grabar en el conjunto de datos de incidencias, si es necesario. Los códigos de error seleccionados se pueden procesar y pasar como parámetros simbólicos a una secuencia de JCL enviada de forma que puede generar registros en una base de datos de problemas o notificar a un ID de usuario de TSO una anomalía determinada. 424 IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste Salidas El miembro EQQX6JOB de SEQQSAMP contiene el JCL del trabajo enviado por EQQX6ASM. EQQUX006 es una salida del comprobador de seguimiento y el resultado satisfactorio o anómalo de una operación lo determina en última instancia el controlador. Salida de cambio de estado de la operación Se invoca la salida de cambio de estado de la operación cada vez que cambia el estado de una operación del plan actual. Esta salida a menudo se utiliza como una interfaz a un sistema de gestión de problemas, como por ejemplo Gestión de información. El miembro EQQX7ASM de SEQQSAMP contiene una salida de cambio de estado de la operación (EQQUX007). Esta salida crea y envía un trabajo por lotes cada vez que el estado de una operación cambia a finalizado con error. El trabajo enviado por la salida, representado por el miembro EQQX7JOB de SEQQSAMP, contiene una CLIST que realiza adaptación específica de los pasos que EQQUX007 le ha pasado. La CLIST genera otro trabajo que se podría utilizar para crear un registro de problema. Si selecciona implementar una interfaz al sistema de gestión de problemas utilizando EQQUX007, recuerde que cada cambio de estado a E invoca la salida. Considere filtrar las operaciones que los usuarios de los diálogos han establecido en error ya que es posible que no representen errores reales. Salida de inicio de la operación IBM Tivoli Workload Scheduler for z/OS invoca la salida de iniciación de operación cuando una operación está preparada para ser iniciada en una estación de trabajo que especifica un ID de destino definido por el usuario. La salida se utiliza para la comunicación con los distintos entornos operativos. En la biblioteca SEQQSAMP se encuentran dos salidas EQQUX009 de ejemplo. El miembro EQQUX9N de SEQQSAMP contiene una salida de iniciación de operación de ejemplo escrita en PL/I. El ejemplo se ha diseñado específicamente para ser utilizado con los ejemplos EQQCVM2 y EQQUX0N que proporcionan un comprobador de seguimiento para un sistema operativo VM, pero se podría modificar para la comunicación con otros entornos operativos. Consulte “Rastreador para VM” en la página 427 para obtener más información sobre el comprobador de seguimiento de VM. El miembro EQQX9OS2 de SEQQSAMP contiene una salida de iniciación de operación de ejemplo escrita en ensamblador. El ejemplo se ha diseñado específicamente para ser utilizado con los ejemplos EQQOS2TR y EQQOS2ST que proporcionan un comprobador de seguimiento para un sistema operativo OS/2, pero se podría modificar para la comunicación con otros entornos operativos. Consulte “Rastreador para OS/2” en la página 428 para obtener más información sobre el comprobador de seguimiento de OS/2. El miembro EQQX9AIX de SEQQSAMP contiene una salida de iniciación de operación de ejemplo escrita en ensamblador. El ejemplo se ha diseñado específicamente para ser utilizado con los ejemplos EQQAIXTR y EQQAIXST que proporcionan un comprobador de seguimiento para un entorno AIX. Puede utilizar estos ejemplos para la comunicación con otros entornos UNIX si el script de shell es compatible. Consulte “Rastreador para AIX” en la página 429 para obtener más información sobre el comprobador de seguimiento de AIX. Apéndice C. Biblioteca de ejemplos (SEQQSAMP) 425 Salidas Salida de sustitución de variables de JCL EQQJVXIT contiene un ejemplo de ensamblador de la salida de sustitución de variables de JCL. Cuando defina una variable de JCL, puede especificar el nombre de la salida que se invocará cuando sea necesaria la sustitución de la variable. Se puede invocar la salida en cualquier configuración de trabajo o envío de trabajo, pero no se puede invocar para variables de configuración con indicador de solicitud. Para variables del mandato de automatización del sistema, la salida se invoca cuando se envía el mandato. Puede utilizar la salida para proporcionar el valor de una variable. Salida de grabación de registro de seguimiento de trabajos El miembro EQQUX011 ilustra un posible caso de ejemplo para utilizar esta salida. Este miembro contiene también el JCL para ensamblar y enlazar el módulo de carga. Salida de catálogo de EQQDELDS/EQQCLEAN EQQDELDS/EQQCLEAN intenta cargar la salida EQQUXCAT. Si el módulo de salida se carga satisfactoriamente, EQQDELDS/EQQCLEAN lo invoca antes de ejecutar la acción de catálogo para cada conjunto de datos implicado. Si la salida devuelve un código de retorno distinto de 0, la acción no se ejecuta y se registra un mensaje para identificar el conjunto de datos que se ha saltado. El ejemplo de salida proporcionado impide la supresión de conjuntos de datos que tengan el calificador que empiece por SYS1.MAC. Salida de resolución de GDG de EQQCLEAN (EQQUXGDG) El programa EQQCLEAN invoca la salida EQQUXGDG inmediatamente antes de ejecutar cualquier acción de sobrescritura de GDG en bloques de control de JES. La acción de sobrescritura no se ejecutará cuando el código de retorno de EQQUXGDG se establezca en un valor