"Tips en breve/Tips en detalle" se envía con frecuencia variable y absolutamente sin cargo como un servicio a nuestros clientes AS/400. Contiene principalmente notas técnicas y no contiene mensajes publicitarios.
Si desea suscribir otra dirección de e-mail para que comience a recibir los "Tips", envíe un mensaje desde esa dirección a letter400@teknoda.com , aclarando nombre, empresa y cargo del suscriptor.

Sometimiento de comandos remotos con SBMRMTCMD

Tema: Interfaces DDM, Comandos CL
Utilidad: Ejecución de comandos en sistemas remotos.
Nivel: Intermedio.
Versión: Todas.

Resumen ejecutivo

En muchas ocasiones es necesario ejecutar tareas en un sistema remoto. Si se posee perfil de usuario y contraseña en el sistema remoto y posibilidades de conexión a través de emulación de pantalla, esas tareas pueden llevarse a cabo abriendo una sesión interactiva en el sistema remoto en cuestión. Cuando es necesario ejecutar un comando puntual o invocar un determinado programa sobre un sistema remoto, OS/400 ofrece alternativas de fácil uso:

• Utilización del mandato SBMRMTCMD (Submit Remote Command) a través del servidor DDM del TCP/IP.
• Facilidades de ejecución de mandatos remotos de Operations Navigator.

La primera de ellas será analizada en el presente tip.

La herramienta perteneciente a Operations Navigator será cubierta en futuros tips.

Introducción

El mandato SBMRMTCMD (Submit Remote Command) permite someter un comando desde un sistema que actúa como cliente hacia un sistema remoto. Esta facilidad es servida a través de un servidor de TCP/IP llamado DDM (Distributed Data Management). Es importante notar que SBMRMTCMD no funciona de la misma manera que SBMJOB. Mientras que SBMJOB somete un job a una cola de trabajos y libera al trabajo sometedor, el job interactivo que, desde el origen ejecuta el SBMRMTCMD, queda a la espera de un mensaje de respuesta desde el sistema remoto, o sea trabaja de manera sincrónica. A través de ese mensaje, el usuario conoce si el mandato sometido en forma remota se ejecutó de manera exitosa o existió algún inconveniente. El siguiente esquema permite conocer quiénes son los "actores" participantes al usar el servidor DDM del TCP/IP:

Por un lado, en el sistema cliente, existe un job que hace un requerimiento, por ejemplo el uso del mandato SBMRMTCMD. En el sistema destino, el servidor DDM escucha los pedidos del sistema cliente por los "well known ports" 446, 447 y 448. Este servidor debe haber sido arrancado previamente con el comando STRTCPSVR SERVER(*DDM) (1). El servidor DDM está soportado, en el sistema destino, por dos trabajos que se ejecutan en el subsistema QSYSWRK y bajo el perfil de usuario QUSER. El primero de ellos, el "listener", con nombre de job QRWTLSTN, es el encargado de escuchar y aceptar el pedido de conexión del cliente, y también de generar un pedido interno para "enlazar" la conexión del cliente con el server job (2). El segundo, el "server job", es un trabajo batch de nombre QRWTSRVR que es sometido cuando el pedido de conexión del cliente es procesado. Este job se ocupará de cualquier otra conexión con el cliente.

Al ejecutar el comando SBMRMTCMD, el intercambio inicial de información que ocurre entre los sistemas incluye el mandato a ejecutar en el sistema remoto junto con el perfil de usuario con el que se ingresará en el sistema remoto (3). Una vez que el perfil de usuario y la contraseña (si es enviada junto con el ID de usuario) fueron validadas, el "server job" ejecutará el mandato bajo el perfil de usuario recibido en el requerimiento (4).

Una vez conocido cómo es el proceso de comunicación a través del servidor DDM, para poder utilizar SBMRMTCMD en forma exitosa, es necesario que se cumplan previamente determinados pasos, que contribuyen a la configuración del entorno:

1. Creación de un archivo DDM (objeto de tipo *FILE con atributo DDMF) en el sistema origen. Este objeto almacenará la dirección IP hacia donde se someterá el mandato.
2. Configuración, en el sistema destino, de los parámetros de seguridad del servidor DDM. Existen parámetros que es imprescindible conocer para que SBMRMTCMD se ejecute exitosamente.
3. Configuración del entorno de seguridad en el sistema origen.
4. Arranque del servidor DDM del TCP/IP en el sistema destino.

Una vez completados, se dispone de la configuración apropiada para la ejecución del comando SBMRMTCMD.

Configuración del entorno

En la presente sección se analizarán los pasos detallados anteriormente:

1- Creación del archivo DDM en el sistema origen

El mandato CRTDDMF es el encargado de crear un objeto de tipo *FILE con atributo DDMF. Observar el siguiente comando ejemplo:

CRTDDMF FILE(QGPL/ARCHDDM) RMTFILE(QGPL/REMOTO) +
RMTLOCNAME('169.145.220.99' *IP) TEXT('Para usar con SBMRMTCMD')

El mandato anterior generará en la biblioteca QGPL un archivo DDM de nombre ARCHDDM. La ubicación hacia donde "apuntará" el archivo será la determinada por la dirección IP 169.145.220.99 (observar que, en el prompt del mandato, *IP no es el valor default). Cuando posteriormente se lo utilice a través del comando SBMRMTCMD, el mandato se ejecutará en el sistema que posea la dirección IP que aquí se indica. En el parámetro RMTFILE debe ingresarse un nombre de archivo que será ignorado cuando se utilice el DDMF a través del comando SBMRMTCMD.

De esta manera queda generado el archivo DDM cuyo nombre será solicitado por uno de los parámetros del mandato SBMRMTCMD.

2- Configuración, en el sistema destino, de los parámetros de seguridad del servidor DDM

Uno de los puntos importantes a considerar dentro de los servicios ofrecidos por el servidor DDM, es el de la seguridad. El servidor DDM posee atributos de seguridad que deben ser analizados. El comando CHGDDMTCPA permite establecerlos. Se necesita autorización especial *IOSYSCFG para poder utilizarlo.
La siguiente pantalla muestra el prompt del mandato:

El primero de los parámetros, Servidor de arranque automático, se utiliza para especificar si este servidor debe arrancarse cuando se ejecute el mandato STRTCP o STRTCPSVR SERVER(*AUTOSTART).

El segundo parámetro, Se requiere contraseña, con palabra clave PWDRQD, determina qué "postura" toma el sistema destino con respecto a la contraseña. Los valores posibles son *YES (default), *NO y *VLDONLY.

PWDRQD(*YES): es el valor default. Exige que se envíe desde el sistema origen un perfil de usuario válido y su respectiva contraseña en el sistema remoto. Cuando esta condición no se cumple, el emisor del comando SBMRMTCMD recibe el mensaje CPF9190: "Anomalía de autorización en un intento de conexión TCP/IP DDM". En la información de ayuda se visualiza "Ha fallado un intento de conexión y el código de razón ha sido 17". Los códigos de razón y sus significados son: "17 -- El servidor no admite o no permite el mecanismo de seguridad que ha solicitado el cliente". Este código de razón revela que el servidor requiere contraseña pero el cliente sólo envía un identificador de usuario y no su contraseña. Esto implica que si se ingresa en la máquina origen con un perfil de usuario y luego se hace una solicitud con el comando SBMRMTCMD al sistema destino, la petición será rechazada, porque el parámetro PWDRQD está en el default *YES y no hay un mecanismo de envío de password establecido. Esto hace notar también que es independiente de que el usuario exista o no en el destino.

Para efectuar el envío de la contraseña junto con el perfil de usuario, deben hacerse seteos de seguridad en el sistema origen, antes de efectuar la primera petición al servidor DDM. Estos seteos se cubrirán en el punto 3, Configuración del entorno de seguridad en el sistema origen.

PWDRQD(*NO): cuando se establece este valor, el servidor DDM no exige contraseña. Si la recibe, la ignora. Los usuarios que desde el sistema origen solicitan servicios del servidor DDM, ingresan en el sistema destino con su perfil de usuario, por lo tanto, el perfil debe existir en el sistema destino. En caso que el perfil de usuario no exista en el sistema destino, se recibirá el mensaje de código CPF9190, con código de razón 5: "No se ha encontrado el usuario en el sistema destino". Debe considerarse que, cuando se utiliza PWDRQD(*NO), todos los usuarios que posean un perfil de usuario en el sistema destino, pueden acceder a los servicios DDM que ese sistema ofrece. Esta capacidad por default no está permitida, debido a que el valor original del parámetro "Se requiere contraseña" es *YES.

PWDRQD(*VLDONLY): el uso de este valor, significa que no exige contraseña, pero si se la envía, debe ser válida. En caso de ser inválida, el emisor de la petición recibe el mensaje de código CPF9190, con código de razón 2: "Contraseña inválida".

3- Configuración del entorno de seguridad en el sistema origen

Solamente en el caso de utilizar el valor *YES para el parámetro "Se requiere contraseña" (palabra clave PWDRQD) del comando CHGDDMTCPA en el sistema destino, deben efectuarse en el sistema origen ciertas tareas que se detallan a continuación:

• Verificar que el contenido del valor del sistema QRETSVRSEC (retener datos de seguridad del servidor) esté establecido en "1" en el sistema origen para que el mandato ADDSVRAUTE que permite el envío de la contraseña, se ejecute exitosamente. Caso contrario, el mandato será rechazado.

• Para efectuar el envío de la contraseña junto con el perfil del usuario, deben realizarse ciertos seteos con el comando ADDSVRAUTE. La siguiente pantalla muestra los parámetros del mandato ADDSVRAUTE que realiza esta tarea:
  

Considerar:

• La posibilidad de "disfrazarse" de otro perfil permite que, un usuario local, acceda al sistema destino bajo otro perfil, sin necesidad de definirle un perfil en el otro sistema que además puede llegar a habilitarlo para otras funciones.

• Es importante destacar que la contraseña que se envía es la incorporada en esta lista, no la que está asociada con el perfil de usuario para accesos normales. Por lo tanto, las modificaciones de contraseñas para los perfiles en el sistema origen, no afectan las entradas de esta lista.

• El comando ADDSVRAUTE USRPRF(PEPE) SERVER(QDDMSERVER) PASSWORD(sssss) incorpora al usuario PEPE en la lista, y cuando solicite los servicios del servidor DDM, se presentará en el destino también como PEPE con la contraseña correspondiente.
• El mandato CHGSVRAUTE permite realizar modificaciones en la entrada de autenticación.

• Si la contraseña del usuario en el sistema remoto se modifica, es necesario también cambiar la entrada correspondiente en el sistema origen. Si esta acción no se realiza, el emisor del mandato SBMRMTCMD recibirá el CPF9190, pero esta vez con código de error 2: "La contraseña no es válida".

• No existen comandos para visualizar cuáles son los usuarios incorporados con ADDSVRAUTE este comando.

• Para remover un usuario de esta lista, usar el comando RMVSVRAUTE.

El mandato ADDSVRAUTE debe ejecutarse tantas veces como sea necesario de acuerdo a la necesidad de incorporar usuarios y sus contraseñas para que puedan conectarse a través del servidor DDM en el sistema destino.

4- Arranque del servidor DDM del TCP/IP en el sistema destino

Una vez realizados los pasos de configuración necesarios, sólo resta arrancar el servidor DDM para completar el proceso. El arranque del servidor DDM se puede realizar manualmente, con el mandato STRTCPSVR SERVER(*DDM) desde cualquier línea de comandos o desde la interfaz gráfica de Operations Navigator ingresando por Red à Servidores à TCP/IP à DDM, botón derecho del mouse e Iniciar.

También puede establecerse su arranque en forma automática para cuando sea arrancado TCP/IP, desde el comando CHGDDMTCPA (parámetro "Servidor arranque automático" establecido en *YES) o desde Operations Navigator ingresando en Propiedades del servidor DDM.

Una vez realizados los pasos necesarios en la configuración, puede accederse a los servicios ofrecidos por el servidor DDM en el sistema destino. En la próxima sección se mostrará el uso del mandato SBMRMTCMD (Submit Remote Command).

Comando SBMRMTCMD

El comando SBMRMTCMD (Submit Remote Command) ofrece la posibilidad de ejecutar un mandato en un sistema remoto. La siguiente pantalla muestra el prompt de comando:

Es importante recordar nuevamente que SBMRMTCMD no funciona de la misma manera que SBMJOB. Mientras que SBMJOB somete un job a una cola de trabajos y libera al trabajo sometedor, el job interactivo que, desde el origen ejecuta el SBMRMTCMD, queda inhibido a la espera de un mensaje de respuesta desde el sistema remoto o sea, trabaja de manera sincrónica.

Cuando en el sistema destino no está arrancado el servidor DDM, el emisor del mandato SBMRMTCMD recibe el mensaje de código CPF9162: "No puede establecerse una conexión DDM con el sistema remoto".

Considerar:

• El parámetro "Mandato a ejecutar" no actúa como una línea de comandos (los mandatos allí escritos no se pueden promptear). Deben escribirse utilizando las palabras claves correspondientes.

• Cuando el comando sometido genera listados en el sistema destino, esas salidas impresas no son automáticamente enviadas al sistema origen. Quedan almacenadas en la cola de salida del usuario con el cual se ingresó al sistema destino. Se podría recurrir al arranque de transcriptores remotos para efectuar el envío automático al sistema origen.

• No todos los comandos CL están orientados a ejecutarse a través del mandato SBMRMTCMD.

• El parámetro "Archivo DDM" debe incluir el nombre del archivo DDM creado anteriormente. En los atributos de este archivo, figura la dirección IP del sistema destino.

Ejemplos de ejecución de SBMRMTCMD

1. SBMRMTCMD CMD( ' CRTPF FILE(BIB1/ARCHI2) SRCFILE(QGPL/QDDSSRC) +
SRCMBR(ARCHI2) ' ) DDMFILE(QGPL/MENDOZA)

Este comando crea en el sistema remoto el archivo físico de datos ARCHI2 en la biblioteca BIB1 usando las especificaciones DDS del miembro fuente ARCHI2 desde el archivo de fuentes QDDSSRC de la biblioteca QGPL. La DDS debe ya existir sobre el sistema destino identificado en el archivo DDM mencionado en el parámetro DDMFILE.

2. SBMRMTCMD CMD( ' CALL PGM(BIB1/PROGRA1) ' ) DDMFILE(QGPL/CORDOBA)

Este comando ejecuta en el sistema destino el programa PROGRA1 de la biblioteca BIB1 (objetos residentes en el sistema destino). El sistema destino es el identificado por archivo DDM mencionado en el parámetro DDMFILE.

3. SBMRMTCMD CMD( ' CHGOBJOWN OBJ(PRUEBA/ARCH) OBJTYPE(*FILE) +
NEWOWN(QSECOFR) ' ) DDMFILE(QGPL/CORDOBA)

Este comando cambia, en el sistema destino, la propiedad del archivo ARCH de la biblioteca PRUEBA otorgándosela al perfil de usuario QSECOFR. El sistema destino es el identificado por archivo DDM mencionado en el parámetro DDMFILE.

4. SBMRMTCMD CMD( ' SAVLIB LIB(STOCK) DEV(*SAVF) SAVF(QGPL/BACKUP) ') +
DDMFILE(QGPL/CORDOBA)

Este comando salva, en el sistema destino, la biblioteca STOCK en un archivo de salvar de nombre BACKUP de la biblioteca QGPL. El sistema destino es el identificado por archivo DDM mencionado en el parámetro DDMFILE. Si en el sistema destino, la unidad de cinta no está preparada, el operador del sistema destino recibirá los mensajes correspondientes.

Para tener en cuenta...

• Como ya expresáramos anteriormente, DDM (Distributed Data Management) es un servidor del TCP/IP. SBMRMTCMD es sólo una de las formas de explotar los servicios que ofrece.

• Los cambios efectuados en el parámetro "Se requiere contraseña" del comando CHGDDMTCPA, entran en vigencia en la siguiente petición de conexión DDM sobre TCP/IP. También pueden cambiarse los valores de este parámetro desde la interfaz Operations Navigator: Red -->Servidores -->TCP/IP -->DDM, botón derecho del mouse y Propiedades.

• Si el mandato SBMRMTCMD es usado para invocar un programa en el sistema destino, los mensajes de escape no monitoreados por el programa son cambiados a mensajes de consulta y enviados al operador del sistema remoto. Si el usuario no desea que el operador del sistema remoto responda a ellos, se puede "planear" la respuesta automática, incorporando los códigos correspondientes en la lista de respuesta del sistema en el sistema remoto.

• Otros comandos que se aplican sobre archivos DDM son WRKDDMF, CHGDDMF y DSPDDMF.

• Los comandos que se aplican sobre entradas de autenticación de servidor son ADDSRVAUTE, CHGSVRAUTE y RMVSVRAUTE.

• Logging: en el sistema destino, la joblog del trabajo de nombre QRWTSRVR en el subsistema QSYSWRK contiene detalles de los servicios prestados por el servidor DDM y también todos los mensajes que recibe el emisor del SBMRMTCMD. El history log del sistema destino almacena entradas que indican los accesos al servidor DDM efectuados por los diferentes usuarios. El siguiente mensaje es un ejemplo de los aparecen allí: " Trabajo DDM 161181/QUSER/QRWTSRVR dando servicio a usuario PEPE en 31/05/02 a las 10:44:50".
  

Copyright Julio 2002 Teknoda S.A . Prohibida su reproducción total o parcial sin citar la fuente.

Dudas o comentarios: letter400@teknoda.com

La información contenida en esta cartilla ha sido recolectada en la tarea cotidiana por nuestros especialistas a partir de fuentes consideradas confiables. No obstante, por la posibilidad de error humano, mecánico, cambios de versión u otro, Teknoda no garantiza la exactitud o completud de la información aquí volcada. AS/400 es marca registrada de IBM. Agradecemos el permiso de IBM para usar sus marcas en esta publicación. iseries400 es marca registrada de IBM. IBM no es el editor de esta publicación y no es por lo tanto responsable de su contenido.