En esta ocasión vamos a realizar la parada y arranque de una tarea del sistema lanzando una aplicación de OPC contra System Automation. Esto nos permitirá parar/arrancar tareas de forma controlada según una planificación. Por ejemplo, una aplicación de OPC que pare el HSM, haga la reorganización y vuelva a arrancar la tarea. La ejecución de estos comandos se hará usando un tipo de Workstations llamadas NVs.
El nombre de la Workstation será “NVxx”, siendo xx, dos letras/números que queramos, por ejemplo, NVA1. Para que esto funcione, deberemos asociar la NV deseada al dominio de NetView en las políticas de System Automation. Además, habrá que definir una tarea “receiver” que este “escuchando” las peticiones de parada/arranque que le llegan.
Para hacer la entrada un poco más completa, voy a incluir algunos errores que se puedan producir.
NOTA: Para que esto funcione, previamente hay que tener definidas las exits de usuario que explicaron en el siguiente enlace:
System Automation - TWS - Alertas jobs en error
Vamos a empezar creando una Workstation de tipo NV en OPC. Deberá tener los parámetros que se ven en la imagen. Es MUY importante que el nombre empiece por NV, en mi caso, NV01.
NOTA: Si hay dudas de cómo crear una WS, en el blog hay una entrada que explica cómo hacerlo.
Una vez la tengamos definida, vamos a crear una aplicación en la base de datos para parar y arrancar una tarea.
NOTA: Si hay dudas de cómo crear una aplicación, en el blog hay una entrada que explica cómo hacerlo.
En la imagen vemos unos datos de ejemplo para la aplicación.
Vamos a OPER y ponemos las siguientes operaciones y predecesores.
NOTA: El nombre de la operación de la NVxx deberá ser el nombre de una tarea que exista en System Automation.
Ahora MUY importante, pondremos el comando TEXT y en el campo “Operation text” pondremos la operación que queremos que realice (Stop, Start o Cancel). En este caso, le pondré Stop a la primera NV y Start, a la segunda. Salimos guardando la aplicación.
Ahora vamos modificar las políticas de System Automation. Para ello, vamos al panel correspondiente y entramos en la opción 1. Como ya implementamos las políticas de System Automation en publicaciones anteriores, utilizaremos la misma base de datos, en mi caso, ADCD113POLICY.
Entramos en la opción 6 – APL – Applications.
Aquí tenemos que buscar una aplicación TWSREQR para asociarla a nuestro sistema. Esta aplicación es la que recibirá las peticiones de parada/arranque de las NVs de OPC. Entramos en la aplicación.
Entramos en la opción Application Info para monitorizar el estado de esta tarea en SDF.
Pulsamos F8 y añadimos el parámetro “Sysname” e “Inform List”, tal y como se ve en la imagen. El resto de campos los dejamos sin modificar. Salimos con F3.
Entramos en la opción Where Used.
Debemos incluir esta aplicación en un grupo de aplicaciones que tengamos asociado a nuestro sistema. En mi caso, usaré el grupo que creamos en entradas anteriores, “TWS_OPC”. Una vez hecho, podemos salir con F3 hasta el listado de políticas.
Ahora entraremos en la opción 20, para confirmar que la NV, que vamos a usar en la aplicación, existe.
Entramos en la opción 31.
Entramos en la única opción que aparece.
Entramos en la opción OPCA PCS.
Comprobamos que en el campo “Netview domain name” tengamos el mismo dominio que creamos al implementar System Automation.
Volvemos al panel de Product Automation y entramos en la opción 33.
Entramos en la única opción disponible.
Entramos en OPCA DOMAINID.
Comprobamos que la NV01 tenga el mismo dominio que el dominio de System Automation. Podemos tener otras NVs.
Volvemos al panel inicial de las políticas de System Automation y entramos a la opción 2 – Build para hacer efectivos los cambios que hemos hecho.
NOTA: Para evitar errores, debemos tener paradas las tareas de System Automation.
Como en entradas anteriores ya construimos la base de datos de políticas, podremos actualizar sólo las políticas de nuestro sistema. Para ello, elegiremos la opción 2 y en el campo Sysplex / System Name pondremos el nombre del sistema.
Pulsamos intro (control) para que empiece el proceso.
Una vez finalizado, aparecerá el mensaje “Build Successful”.
Por último, debemos añadir el usuario “AUTOPCP” en el grupo NVOPS2 dentro del fichero CNMSCAT2 para otorgarle permisos para ejecutar comandos.
NOTA: Se darán permisos de esta forma, siempre y cuando lo tengamos definido de esta manera. Si utilizamos RACF, u otro sistema, para dar estos permisos, deberemos hacer la modificación dónde corresponda.
Ya podremos arrancar System Automation.
NOTA: Es posible que haya que hacer una extensión del current plan/replan para que System Automation coja la nueva workstation.
Ahora iremos a la opción 5.1 de OPC y añadiremos la aplicación que creamos al principio. En el siguiente vídeo se observa el resultado.
POSIBLES ERRORES
Si al lanzar la aplicación, falla, buscaremos en el log de NetView (comando “blog”) el error que se está produciendo. Por ejemplo:
Si el error que se produce en TWS es “UNTV” y en log de NetView vemos que aparece el mensaje “EVJ102I EVJ07001: PPI request 0002 failed, RC=0026”. Esto es debido a que la tarea “TWSREQR” no está definida en nuestro sistema. Quizá no asociamos la tarea al sistema correcto cuando modificamos las políticas, tal y como vimos en esta entrada.
En este enlace podemos ver los códigos de error que se pueden producir para encontrar la solución.
Si, al lanzar la aplicación por OPC, la operación se queda en estado Ready, deberemos buscar el error que se produce en el log de NetView.
En este caso, vemos que el usuario AUTOPCP no tiene autorización para ejecutar comandos.
Debemos añadir el usuario “AUTOPCP” en el grupo NVOPS2 dentro del fichero CNMSCAT2 para otorgarle permisos para ejecutar comandos.
Después pararemos y arrancaremos System Automation.
NOTA: Se darán permisos de esta forma, siempre y cuando lo tengamos definido de esta manera. Si utilizamos RACF, u otro sistema, para dar estos permisos, deberemos hacer la modificación dónde corresponda.
Una vez hecho esto, ya podremos parar/arrancar tareas del sistema usando workstations de tipo NVxx.