Después de definir las WorkStations, calendario y una aplicación, en esta entrada crearemos el Long Term Plan y el Current Plan para ejecutar esa aplicación. Los pasos son muy similares a los seguidos en la versión 8.6, pero aquí veremos cómo modificar los esqueletos que utiliza TWS para ejecutar los jobs para crear el Long Term Plan y el Current Plan. También corregiremos un parámetro que nos faltó durante la instalación de TWS 9.3.
Esta entrada será muy similar a las que ya existen en el blog para la versión 8.6, pero lo haremos para comprobar que hicimos correctamente la instalación del producto.
En la segunda parte creamos los dataset que usará TWS. También creamos y editamos los ficheros de configuración que se usaran para Controller y Tracker. En esta tercera entrada terminaremos de implementar la herramienta.
Seguimos con la implementación de Tivoli Workload Scheduler 9.3. El último paso que hicimos fue compilar las exits necesarias para el funcionamiento de la herramienta.
Hace tiempo escribí cómo implementar Tivoli Workload Scheduler 8.6, en esta ocasión será la versión 9.3. Desde hace un tiempo le cambiaron el nombre al producto y le empezaron a llamar IBM Z Workload Scheduler (IWS). Antes de llamarse Tivoli Workload Scheduler (TWS), se llamaba Operations Planning and Control/ESA (OPC/ESA) o, simplemente, OPC.
Es un proceso muy parecido, aunque he cambiado el orden de los pasos para adaptarme al manual de IBM. La configuración será un Controller y un Tracker en el mismo sistema.
En esta segunda y última parte vamos a terminar implementar el tracker del sistema secundario, haremos la configuración del controller del sistema principal y probaremos que todo funciona.
En esta entrada se plantea la siguiente situación: ya tenemos un controller y un tracker de TWS en un sistema principal y, en otro sistema, queremos crear un tracker para conectarlo al controller del sistema principal. La comunicación entre controller y tracker puede ser por SNA, TCPIP o XCF. En este caso vamos a usar TCPIP. Dejo un vídeo del objetivo que queremos.
Cuando intentamos buscar con “FIND” una operación concreta dentro de una aplicación de OPC, nos mostrará un mensaje indicando que no es un comando válido y tenemos que ir buscando uno por uno hasta encontrar la operación deseada. Si esa aplicación tiene 100 o más operaciones, pierdes mucho tiempo. Cuando estamos buscando una aplicación en la opción 5.2 de OPC si podremos buscar una concreta usando "LOCATE nombre_aplicacion" (o "LOC nombre_aplicación"), pero no servirá para buscar operaciones.
En la primera parte estuvimos instalando el sistema AsteriskNow y creando un nuevo usuario para ejecutar los scripts. En esta segunda y última parte, añadiremos los scripts que harán la llamada automática y haremos una prueba desde z/OS para confirma que funciona.
Vamos a empezar a configurar Asterisk. Ponemos la IP que apuntamos al principio (en mi caso, 192.168.1.21) en un navegador y entramos en la web de FreePBX.
Esta vez voy a crear un aviso telefónico automático cuando falle un job de OPC, es decir, recibiremos una llamada de teléfono que se realizará de forma automática y nos informará del job que ha terminado en error. A lo mejor no es una idea que se pueda utilizar en un entorno de Producción, pero me apetecía probarla.
Aquí pongo un vídeo del resultado.
En esta entrada vamos a combinar varias cosas: una aplicación que sea cíclica con dos jobs que se ejecutará cada 10 minutos. Además el segundo job de esta aplicación, sólo se ejecutará si uno de los pasos del job anterior ha terminado con RC=04 y su estado es “completo”. Este segundo job añadirá una nueva aplicación al Current Plan usando OCL (OPC Control Language).
En OPC (TWS), para poder comprobar si las variables de OPC de un JCL son correctas, hay que submitirlo con algún error de sintaxis (para no ejecutar algo de forma indebida) y comprobar si falla por OJCV. En esta ocasión vamos a añadir una nueva opción a OPC que consiste en poder comprobar si las variables de OPC de un JCL son correctas sin tener que submitir ese JCL.
Esta nueva opción va a tener dos versiones, la primera que consiste en dar un comando para ejecutar un REXX y la segunda que consiste en ejecutar otro REXX, pero mediante una opción nueva en un panel. La segunda versión la veremos en otra entrada.
En esta entrada vamos a añadir dos nuevas funciones al panel de errores de OPC (5.4). La primera consiste en añadir la hora del sistema. Nos puede venir bien para saber si el panel se ha quedado “pillado” cuando trabajamos monitorizando procesos en error. También vamos a añadir una nueva opción al panel para ver la salida de un job fallado sin tener que ir a buscarlo al spool.
Después de haber creado el Current Plan y de haber comprobado las aplicaciones que tenemos en la planificación, vamos a ver cómo revisar las operaciones en error que tenemos de esas aplicaciones planificadas.
Desde el panel principal de OPC, entramos a la opción 5.
En esta entrada vamos a explicar como hacer la extensión del Current Plan para hacer la planificación del día. Para que funcione correctamente, además del Controller de OPC, debemos tener arrancado el Tracker.
Desde el menú principal de OPC, vamos a la opción 3 (Daily Planning).
El Long Term Plan (LTP) es el plan a largo plazo y se crea a partir de los ciclos de ejecución que hemos definido y de las aplicaciones que hemos creado en post anteriores. Se puede crear el plan a largo plazo de varios años y después modificarlo, añadiendo o quitando aplicaciones, según se necesite.
Desde la pantalla principal de OPC, vamos a la opción 2.
Después de ver cómo crear WorkStations y cómo crear calendarios y ciclos de ejecución, vamos a crear una aplicación para que se ejecute según lo establecido anteriormente. La aplicación que vamos a crear solo tendrá tres operaciones: una operación de inicio y otra final y un job en el que escribiremos mal el JCL para arreglarlo cuando falle y poder relanzarlo.
Vamos a empezar creando el job que acabamos de mencionar. Para ello, vamos a la librería JOBLIB de OPC, en este caso es OPC.OP1C.JOBLIB. Ahí creamos un miembro llamado PRIMERO. Para hacer esto, cogemos cualquier JCL que ya exista, por ejemplo de la librería OPC.OP1C.JOBLIB, copiamos la JOBCARD y creamos el miembro con el comando “CREATE OPC.OP1C.JOBLIB(PRIMERO)”.
En esta ocasión vamos a crear el calendario y los períodos de ejecución que usarán nuestras aplicaciones. Sirve para definir los días que deberán ejecutarse. En el calendario definimos los días que son "de trabajo", es decir, aquellos días que las aplicaciones que usen ese calendario se ejecutarán, por ejemplo, de lunes a viernes. También definimos los días "libres", esos días las aplicaciones no se ejecutarán, por ejemplo, fines de semana y días festivos.
Vamos a crear algunas Workstations (WS) que usaremos cuando creemos las operaciones (jobs) de las aplicaciones. Sirven para ejecutar jobs, parar la ejecución de una aplicación en un punto determinado, para controlar el inicio o el fin de una aplicación, etc.
Con el controller arrancado (el tracker no hace falta), entramos en OPC y vamos a la opción 1 para modificar la base de datos.
En esta última parte, vamos a crear los nodos de VTAM que necesita el OPC para establecer la comunicación entre el controller y el tracker. También corregiremos algunos detalles de la instalación que han quedado pendientes. Una vez hecho esto, daremos por finalizada la implementación básica de OPC. En otras entradas del blog, veremos cómo crear workstations, aplicaciones, calendarios, etc.
En esta cuarta y penúltima parte, vamos a empezar editando la librería de parámetros del sistema, es decir, la librería ADCD.Z113.PARMLIB. Hay que hacer los siguientes cambios:
NOTA: Estos cambios son para el LOADPARM con el que hayamos arrancado el sistema. Por ejemplo, si arrancamos con el LOADPARM que arranca lo básico, modificamos los miembros y luego arrancamos con otro LOADPARM que arranque DB2, habrá que modificar los miembros que usa ese LOADPARM para que funcione OPC.
En esta tercera parte, vamos a empezar copiando el miembro EQQCONO de la librería OPC.OP1C.SAMPJCL a la librería PROCLIB del sistema, en este caso, ADCD.Z113.PROCLIB.
Una vez hechos los pasos de la entrada Implementando TWS 8.6.0 (OPC) - Primera Parte, vamos a continuar con la instalación. En esta segunda entrada vamos a modificar y a ejecutar los JCLs que crean todas las librerías que luego usará OPC. Los cambios son mínimos y son muy simples.
Nos encontramos en la opción 3.4 de ISPF y vamos a editar la librería OPC.OP1C.SAMPJCL.
Vamos a implementar TWS 8.6.0 en Hercules. Será una instalación sencilla, pero servirá para poder aprender a planificar y utilizar muchas de las funciones de TWS. Como referencia usaremos los manuales de instalación de IBM. Aquí dejo el enlace a los manuales que están en la web de IBM. Pongo en manual en español y en inglés, porque la traducción al español puede confundir.
Manual en español: TWS 8.6.0 - Planificación e instalación
Manual en inglés: TWS 8.6.0 - Planning and installation
La primera parte consiste en ejecutar la aplicación EQQJOBS, que se encarga de generar unas librerias con JCLs de ejemplo para hacer la instalación. Primero tenemos que ver el procedimiento de logon que usamos en TSO.