En esta ocasión instalaré la consola de administración de IBM Workload Scheduler llamada Dynamic Workload Scheduler (DWC). Sirve para administrar la planificación desde una interfaz gráfica. Además, es necesario tener la DWC para poder disponer de las REST API y hacer consultas contra el planificador de z/OS.
Hay varias versiones que se pueden instalar (Linux, Windows, z/OS…), pero yo elegiré las imágenes Docker ya que a mí me parecen las más sencillas.
Hay dos versiones: la “s390x” y la normal. La versión s390x sirve para ser usada en un Linux dentro de Mainframe o en zCX (contenedores en z/OS).
Yo empezaré eligiendo la versión normal. Más adelante, si tengo tiempo, haré la instalación en zCX también.
Descargaré Docker Desktop para Windows:
Abrimos el fichero descargado y lo instalamos.
Usaré estas opciones.
Reinicio el sistema.
Al abrir el programa, me salió un mensaje indicando que tenía que instalar “WSL 2”.
Pinché en el enlace, lo descargué y lo instalé.
Descarga del paquete de actualización del kernel de Linux
Ahora descomprimiré el software descargado, en mi caso, el contenedor para arrancarlo en mi pc (la versión normal, no la versión Mainframe, s390x).
Lo importante es leer el fichero README. Ahí indica que necesitaremos una base de datos para poder arrancar DWC.
La base de datos la usaré desde Docker también. En mi caso, voy a elegir DB2. Para poder descargar esta imagen, entraremos en https://hub.docker.com/ y buscaremos ibmcom/db2.
El enlace directo es:
https://hub.docker.com/r/ibmcom/db2
Tenemos que copiar el comando:
docker pull ibmcom/db2
Abrimos un CMD de Windows y ponemos el comando para descargar la última imagen disponible.
Después podemos comprobar que tenemos la imagen con el comando:
docker image ls
Si miramos en Docker Desktop, también veremos la imagen.
Ahora tendremos que arrancar la imagen. En el enlace https://hub.docker.com/r/ibmcom/db2 podremos ver el comando para arrancar DB2.
El comando de ejemplo será:
docker run -itd --name mydb2 --privileged=true -p 50000:50000 -e LICENSE=accept -e DB2INST1_PASSWORD=<choose an instance password> -e DBNAME=testdb -v <db storage dir>:/database ibmcom/db2
En mi caso, quedará así:
docker run -itd --name mydb2 --privileged=true -p 50000:50000 -e LICENSE=accept -e DB2INST1_PASSWORD=1234 -e DBNAME=DWC -v C:/Users/jav/Docker:/database ibmcom/db2
Usaré el comando desde un CMD. Después comprobaré que está arrancado con el comando:
docker container ls
Ahora podemos comprobar el log con el comando:
docker logs -f <your_container_name>
En mi caso será:
docker logs -f 59539869ae61
En el log comprobaremos que ha arrancado bien.
Como curiosidad, podemos ver los ficheros que se han creado en la ruta que indicamos en el comando de arranque.
En principio, ya tenemos la base de datos funcionando.
Ahora vamos a cargar la imagen de DWC. Para ello, desde un CMD vamos a la ruta en la que extrajimos el contenedor. Después usaremos el comando para cargar el archivo “workload-automation-console.tar”:
docker load -i workload-automation-console.tar
Si miramos las imágenes cargadas, ahí la tendremos.
Ahora lo que indica el fichero README es que debemos generar un fichero “.sql” para la base de datos. Para hacerlo, ejecutamos el comando:
docker run --rm ibm-workload-automation-console:9.5.0.06.202206140749 cat /opt/dwc/tools/create_database.sql > create_database.sql
NOTA: el nombre de la imagen deber ser el mismo que aparece al listar las imágenes (incluido el número de versión).
Tendré el fichero en la misma ruta desde donde he ejecutado el comando (en mi caso C:\Users\jav\Desktop\DWC).
Al ver el fichero, me he dado cuenta de que solo crea la base de datos, pero no crea tablas ni otros recursos, por lo tanto, no lo voy a ejecutar en DB2 porque ya creé la base de datos DWC cuando arranqué el contenedor.
El siguiente paso será arrancar el contenedor de la aplicación DWC.
El comando que indica la documentación es el siguiente:
docker run \
-d -e LICENSE=ACCEPT \
-e WA_PASSWORD=wa_password \
-e DB_TYPE=db_type \
-e DB_HOSTNAME=db_hostname \
-e DB_PORT=db_port \
-e DB_NAME=db_name \
-e DB_USER=db_user \
-e DB_PASSWORD=db_password \
-e DB_ADMIN_USER=db_admin_user \
-e DB_ADMIN_PASSWORD=db_admin_password \
-v workload-automation-console-data:/home/wauser \
ibm-workload-automation-console:9.5.0.06.\<release_date>
Aquí dejo los valores sencillos que he usado (sobre todo las passwords). Evidentemente esto es para una prueba y pongo passwords sencillas. En un entorno real es muy importante tener en cuenta la seguridad.
Importante incluir el parámetro “-p 9443:9443” para que el contenedor escuche en el puerto 9443 y lo redirija al 9443 al puerto de la aplicación DWC.
docker run -d -p 9443:9443 -e LICENSE=ACCEPT -e WA_PASSWORD=1234 -e LANG=en -e DB_TYPE=DB2 -e DB_HOSTNAME=192.168.1.10 -e DB_PORT=50000 -e DB_NAME=DWC -e DB_USER=db2inst1 -e DB_PASSWORD=1234 -e DB_ADMIN_USER=db2inst1 -e DB_ADMIN_PASSWORD=1234 -v workload-automation-console-data:/home/wauser ibm-workload-automation-console:9.5.0.06.202206140749
Comprobamos que el contenedor ha arrancado y el ID.
Revisamos el log hasta que arranque el producto.
Confirmamos que ha terminado de arrancar.
Ya podemos acceder la web. Yo uso la IP de mi sistema donde se ejecuta Docker y la URL de la aplicación DWC.
https://192.168.1.10:9443/console/login.jsp
Usaré el usuario wauser para acceder y la password que indiqué en el arranque (docker run…)
Como vemos, podemos entrar.
Ahora el objetivo es conectar la consola con el planificador de z/OS. Seguiremos los siguientes pasos:
Lo primero será crear el servidor en z/OS:
Activating server support for the Dynamic Workload Console
Para crear el servidor necesitamos la SCT y el fichero de parámetros. Los ejemplos se encuentran en **.SAMPJCL.
Copiamos EQQSER a la PROCLIB. Le cambiaré el nombre a OPCCSERV.
Copiamos EQQSERP a la librería de parámetros de OPC (en mi caso, OPC.V950.PARM).
Vamos a editar el miembro EQQSERP. A partir de ahí crearemos otros dos ficheros.
Miembro SERP. En vez de usar ese nombre, lo llamaré OPCCSERP.
También hay que crear el fichero de usuarios (miembro USERS). Yo lo crearé con el nombre OPCCUSER.
Editaré el miembro OPCCSERP.
Indicaré el SUBSYS (OPCC, en mi caso) y el parámetro USERMAP es el miembro creado en el paso anterior. En el parámetro CALENDAR tenemos que poner el nombre del calendario de la base de datos que queramos usar. En mi caso, tengo uno llamado CALENDARIO.
Además, añadiré el siguiente parámetro para indicar la loca IP (no se si es necesario, pero por si acaso).
JSCHOSTNAME(192.168.1.12)
Los calendarios disponibles los podemos ver en la opción 1.2.1 de OPC.
En el miembro OPCCUSER debemos añadir los usuarios para que puedan conectarse al servidor. Yo de momento lo dejo por defecto o mejor aún, no ponemos ninguno.
Después explicaré la forma sencilla de añadirlos.
En el fichero de parámetros del Controller de OPC, añadiré el siguiente parámetro para que arranque el servidor automáticamente cuando arranque el controller.
SERVERS(nombre_STC)
SERVERS(OPCCSERV)
El siguiente paso será adaptar la STC. Pondré el nombre correcto de la STC y el miembro de parámetros.
Ahora podemos arrancar la STC con el comando S OPCCSERV.
Arrancará correctamente.
En el fichero MLOG (DD EQQMLOG de la STC) podemos ver que el arranque fue bien y los datos de conexión.
Ya tenemos preparada la parte de z/OS. Ahora iremos a hacer la parte de la consola DWC.
Tenemos que crear el “zConnector” que sirve para conectar con el servidor que hemos arrancado en z/OS.
Usaré los siguientes enlaces de referencia:
CONNECT THE DWC 9.5 TO A z/OS ENVIRONMENT
Defining a z/OS engine in the Z connecto
Para definir el zConnector, haremos lo siguiente.
Primero hay que conectarse al contenedor de DWC. Con Docker Desktop es muy fácil, solo tenemos que abrir la consola del contenedor.
Se abrirá un terminal y ahí tendremos que ir a la ruta “/opt/dwc/usr/servers/dwcServer/configDropins/templates/zconnectors” para copiar la plantilla de configuración (connectionFactory.xml).
cd /opt/dwc/usr/servers/dwcServer/configDropins/templates/zconnectors
Copiaremos ese fichero a la ruta “/home/wauser/wadata/usr/servers/dwcServer/configDropins/overrides”
cp connectionFactory.xml /home/wauser/wadata/usr/servers/dwcServer/configDropins/overrides
Ahora vamos a esa ruta y abrimos el fichero con el editor “vi”:
cd /home/wauser/wadata/usr/servers/dwcServer/configDropins/overrides
vi connectionFactory.xml
Dejo un enlace con los comandos de vi:
https://docs.oracle.com/cd/E19620-01/805-7644/6j76klopr/index.html
Para editar, hay que pulsar la tecla “i” y entraremos en modo “Insert”.
Editamos lo que queramos del fichero y pulsamos “ESC” para volver al modo comando.
Para guardar y salir, escribimos à :wq
Para salir sin guardar, escribimos à :q!
El manual indica que debemos poner el nombre de host en el fichero TWSZOSConnConfig.properties. Vamos a la ruta y lo editamos con vi:
cd /home/wauser/wadata/usr/servers/dwcServer/resources/properties/
vi TWSZOSConnConfig.properties
Yo pondré la IP del sistema donde tengo ejecutando Docker.
Para poder conectar con el Controller de z/OS es importante el usuario que se use. Este usuario tiene que estar definido en DWC y también en z/OS (RACF en mi caso).
Como yo ya tengo definido el usuario IBMUSER en RACF, lo voy a incluir en DWC para poder conectar con el Controller. De esta forma, “ahorro” trabajo para esta prueba.
Para añadir usuarios, seguiré este documento:
How to add new user for Dynamic Workload Console V9.5 and Tivoli Workload Scheduler V9.5
Vamos a la ruta /opt/dwc/usr/servers/dwcServer/configDropins/overrides y modificamos el fichero:
cd /opt/dwc/usr/servers/dwcServer/configDropins/overrides
vi authentication_config.xml
Otro dato importante es saber qué puerto deberemos usar cuando añadamos la conexión al Controller (se entenderá mejor más adelante). Para saberlo, tenemos que revisar el fichero “ports_variables.xml”.
cd /opt/dwc/usr/servers/dwcServer/configDropins/overrides
vi ports_variables.xml
Ahora tendremos que añadir la conexión con el OPC de z/OS. Entramos DWC (yo lo haré con el nuevo usuario “ibmuser”) y vamos a Administración, Gestionar Motores.
Pinchamos en Nuevo.
Esta conexión solo podrá ser editada por el usuario que la crea.
Elegiré el tipo de motor z/OS. Como nombre de host dejaremos localhost y pondremos el puerto que vimos en el fichero ports_variables.xml (19402).
El nombre de servidor remoto es el id del zConnector OPCCZCON (fichero connectionFactory.xml).
Como usuario usaré el usuario ibmuser (fichero authentication_config.xml).
Pulsaremos Probar Conexión y la primera vez fallará.
El error indicará el usuario que debemos definir en el fichero USERMAP de z/OS.
AWSUI0766E Probar conexión con [OPCC]: ha fallado.
AWSUI0833E La operación no se ha podido completar. Se ha producido un error de comunicación.
El mensaje interno es: AWSJCO005E WebSphere Application Server has given the following error: javax.ejb.EJBException: See nested exception; nested exception is: com.ibm.tws.zconn.pif.PifException: EQQPH25E TME USER ID MISSING IN RACF CLASS TMEADMIN: Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo..
Vamos al miembro OPC.V950.PARM(OPCCUSER) que vimos en pasos anteriores y añadimos el usuario@host.
USER Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.' RACFUSER(IBMUSER)
En el siguiente enlace hay más información:
Mapping a Dynamic Workload Console user ID to a RACF user ID
Paramos y arrancamos la tarea OPCSERV para que coja los cambios.
Ahora, al probar de nuevo la conexión desde DWC, conectará.
Aceptamos la configuración.
Podemos compartir la configuración para que otros usuario dispongan de la conexión, pero solo podrá editar la configuración el usuario que lo ha creado.
Podremos compartirlo con todos los usuarios o con grupos (los grupos habrá que definirlos en el fichero authentication_config.xml)
Por último, veremos el panel de control del OPC de z/OS.
Veremos la siguiente información (en mi caso, hay muy pocas cosas).
Si entro a ver los jobs que han ido bien, podremos ver información sobre estos (pinchando en la barra verde del panel Job status).
Como curiosidad añadiré que durante las pruebas tuve un error de arranque. El log del contenedor indicaba lo siguiente. Nos fijamos en la ruta del fichero log:
WAINST007I Starting server dwcServer ...
WAINST015E The following command failed: /opt/dwc/appservertools/startAppServer.sh -direct
WAINST035I For more details see the installation log file: /home/wauser/wadata/installation/logs/dwcinst_9.5.0.06.log.
I: Customizing datasource.xml
I: Customizing datasource.xml nothing to do
E: Error configuring console.
E: Error starting instance.
Para ver el log, vamos a Volumes y elegimos “workload-automation-console-data”.
Vamos a la pestaña DATA, buscamos el log que vimos en el paso anterior y lo descargamos.
Veremos un mensaje indicando que el servidor ya se está ejecutando.
En mi caso, paré Docker, reinicié el PC, borré el contenedor y lo volví a crear. Seguía apareciendo el mismo error. Finalmente encontré este enlace:
The CLM startup scripts for WebSphere Liberty indicate the server is already started when it is not
Siguiendo las instrucciones borré los ficheros .sCommand y .sRunning de la ruta wadata/stdlist/appserver/dwcServer/workarea y el servidor arrancó correctamente.
Por algún motivo no debieron borrarse con la parada anterior del servidor. Me ha pasado en un par de ocasiones, pero es fácil de resolver.
Espero que os haya gustado esta entrada sobre DWC. Es de las que más me ha gustado hacer.