IBM Tivoli Workload Scheduler for z/OS: Personalización y ajuste

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