• principal_3

    Desde 2015, enseñando sobre el sistema operativo z/OS de IBM en esta web. z/OS se utiliza en máquinas llamadas Mainframe.

  • principal_1

    Para realizar el contenido, utilizo el producto de IBM llamado z/Development and Test Environtment Personal Edition. Este software permite emular un Mainframe y así poder utilizar z/OS para aprender.

  • principal_2

    Es utilizado por grandes empresas (bancos, aseguradoras...). Aquí aprenderás a instalar y configurar productos relacionados con z/OS.

  • principal_4

    ADCD es una distribución de z/OS que contiene productos de IBM como IMS, DB2, CICS, ZOWE, TWS, NetView, System Automation, etc.

IWS Dynamic Workload Console - Instalación en Docker y conexión con Controller z/OS
Featured

IWS Dynamic Workload Console - Instalación en Docker y conexión con Controller z/OS

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.

001 watermark

 

Descargaré Docker Desktop para Windows:

Docker Desktop

002 watermarkA

 

Abrimos el fichero descargado y lo instalamos.

003 watermark

 

Usaré estas opciones.

004 watermark

 

Reinicio el sistema.

005 watermark

 

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

006 watermark

007 watermark

 

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).

008 watermark

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

009 watermark

 

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

010 watermark

 

Si miramos en Docker Desktop, también veremos la imagen.

011 watermark

 

Ahora tendremos que arrancar la imagen. En el enlace https://hub.docker.com/r/ibmcom/db2 podremos ver el comando para arrancar DB2.

012 watermark

 

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

013 watermark

 

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.

014 watermark

 

Como curiosidad, podemos ver los ficheros que se han creado en la ruta que indicamos en el comando de arranque.

015 watermark

 

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”:

016 watermark

 

docker load -i workload-automation-console.tar

017 watermark

 

Si miramos las imágenes cargadas, ahí la tendremos.

018 watermark

 

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).

019 watermark

 

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.

020 watermark

 

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

021 watermark

 

Comprobamos que el contenedor ha arrancado y el ID.

022 watermark

 

Revisamos el log hasta que arranque el producto.

023 watermark

 

Confirmamos que ha terminado de arrancar.

024 watermark

 

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…)

025 watermark

 

Como vemos, podemos entrar.

026 watermark

 

Ahora el objetivo es conectar la consola con el planificador de z/OS. Seguiremos los siguientes pasos:

Prerequisites

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.

027 watermark

 

Copiamos EQQSERP a la librería de parámetros de OPC (en mi caso, OPC.V950.PARM).

028 watermark

 

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.

029 watermark

030 watermark

 

También hay que crear el fichero de usuarios (miembro USERS). Yo lo crearé con el nombre OPCCUSER.

031 watermark

 

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)

032 watermark

 

Los calendarios disponibles los podemos ver en la opción 1.2.1 de OPC.

033 watermark

 

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.

034 watermark

 

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)

035 watermark

 

El siguiente paso será adaptar la STC. Pondré el nombre correcto de la STC y el miembro de parámetros.

036 watermark

 

Ahora podemos arrancar la STC con el comando S OPCCSERV.

Arrancará correctamente.

037 watermark

 

En el fichero MLOG (DD EQQMLOG de la STC) podemos ver que el arranque fue bien y los datos de conexión.

038 watermark

 

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.

039 watermark

 

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

040 watermark

 

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

041 watermark

 

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

042 watermark

043 watermark

 

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!

044 watermark

 

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

045 watermark

 

Yo pondré la IP del sistema donde tengo ejecutando Docker.

045a watermark

 

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

048 watermark

049 watermark

 

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

050 watermark

051 watermark

 

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.

046 watermark

 

Pinchamos en Nuevo.

Esta conexión solo podrá ser editada por el usuario que la crea.

047 watermark

 

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á.

052 watermark

 

 

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: This email address is being protected from spambots. You need JavaScript enabled to view it..

053 watermark

 

Vamos al miembro OPC.V950.PARM(OPCCUSER) que vimos en pasos anteriores y añadimos el usuario@host.

USER This email address is being protected from spambots. You need JavaScript enabled to view it.'  RACFUSER(IBMUSER)

En el siguiente enlace hay más información:

Mapping a Dynamic Workload Console user ID to a RACF user ID

054 watermark

 

Paramos y arrancamos la tarea OPCSERV para que coja los cambios.

055 watermark

 

Ahora, al probar de nuevo la conexión desde DWC, conectará.

056 watermark

 

Aceptamos la configuración.

057 watermark

 

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.

058 watermark

 

Podremos compartirlo con todos los usuarios o con grupos (los grupos habrá que definirlos en el fichero authentication_config.xml)

059 watermark

 

Por último, veremos el panel de control del OPC de z/OS.

060 watermark

 

Veremos la siguiente información (en mi caso, hay muy pocas cosas).

061 watermark

 

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).

062 watermark

 

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.

063 watermark

 

Para ver el log, vamos a Volumes y elegimos “workload-automation-console-data”.

064 watermark

 

Vamos a la pestaña DATA, buscamos el log que vimos en el paso anterior y lo descargamos.

065 watermark

 

Veremos un mensaje indicando que el servidor ya se está ejecutando.

066 watermark

 

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.

067 watermark

 

Espero que os haya gustado esta entrada sobre DWC. Es de las que más me ha gustado hacer.

 

 

Related Articles

Free Joomla! templates by Engine Templates