Cola de trabajos independiente

A veces hemos tenido la necesidad de aislar ciertos tipos de trabajo para que se ejecuten en orden secuencial; como la cola de trabajos QBATCH (asignada al subsistema QBATCH), puede, por omisión, ejecutar varios trabajos simultáneamente, no podemos utilizar esa cola para ejecutar trabajos secuencialmente.

Para crear una cola de trabajos independiente y asignarla al subsistema QBATCH, para que ejecute trabajos de uno en uno seguiremos los siguientes pasos:

1. Crear una nueva cola de trabajos donde someteremos los trabajos que queramos ejecutar secuencialmente:
2. CRTJOBQ JOBQ(QGPL/QBATCH1X1) TEXT('Job queue for run one by one')
3. Asignar esa nueva cola de trabajos al subsistema QBATCH:
4. ADDJOBQE SBSD(QBATCH) JOBQ(QGPL/QBATCH1X1) MAXACT(1) SEQNBR(15)
5. El numero de secuencia (SEQNBR) sera el orden de cola que el subsistema utilizará para ejecutar los trabajos.
6. Puede ser necesario ampliar el numero máximo de trabajos que se ejecutan en el subsistema QBATCH, y que por omisión es *NOMAX. Para comprobarlo DSPSBSD QBATCH opción 1 y ver el numero máximo de trabajos en el subsistema. Para cambiarlo usar CHGSBSD SBSD(QSYS/QBATCH) MAXJOBS(jobs que existan + 1)
   
7. También podemos modificar las descripciones de trabajo, que creamos conveniente, para que se sometan siempre por esa cola de trabajos:
8. CHGJOBD JOBD(mylib/myjobd) JOBQ(QGPL/QBATCH1X1)

Cola de mensajes QSYSMSG

El sistema operativo del AS400 tiene una función oculta y especial para enviar los mensajes que requieran alguna acción por parte del usuario (operador o administrador), a la cola de mensajes especial QSYSMSG. Esta cola de mensajes no existe al instalar el sistema operativo y debemos de crearla manualmente:

CRTMSGQ MSGQ(QSYS/QSYSMSG) TEXT('Special system messages queue') MSGQFULL(*WRAP)

Otorgamos la propiedad a QSECOFR: 

CHGOBJOWN OBJ(QSYS/QSYSMSG) OBJTYPE(*MSGQ) NEWOWN(QSECOFR)

Con esto los mensajes de cierta gravedad se escribirán en la cola de mensajes QSYSMSG, ademas de en la cola QSYSOPR. Esto puede facilitarnos la monitorización de mensajes del sistema.

Podéis encontrar información sobre esta funcionalidad en el IBM Information Center

Controlar trabajos batch

Para averiguar la duración de un trabajo batch, que no ha dejado rastro (joblog), podemos utilizar el histórico del sistema para ver cuando se arranco, cuando finalizo y con que código.

Para ello debemos utilizar el mandato DPSLOG, por ejemplo para ver la duración del trabajo MYJOB del usuario QUSER, del cual no sabemos el numero de trabajo, pero si que se debió ejecutar el día 30 de abril por la tarde:

DSPLOG PERIOD((120000 300409)) JOB(QUSER/MYJOB) MSGID(CPF1124 CPF1164)

Con esto obtendremos el siguiente resultado:El message id CPF1124 nos indica la hora de arranque del trabajo y el CPF1164 la hora de terminación y con que código; para ver el código hemos de situar el cursor sobre la línea del mensaje y pulsar F1, con ello podremos ver la siguiente pantalla:

Ahí podremos ver el código de terminación, en el ejemplo 0.

• Si un trabajo tiene código de terminación 10, puede que haya terminado correctamente.
• Si pulsamos Av.Pag. podremos ver la razón de todos los códigos de terminación.
• Si pulsamos la tecla F6 imprimiremos este mensaje en nuestro el spool.
• Si volvemos a ejecutar el mismo mandato DSPLOG, pero sin el parámetro MSGID, veremos todos los mensajes que el trabajo ha enviado al histórico del sistema.
• Si pulsamos la tecla F9 sobre el mensaje podremos ver que programa ha grabado el mensaje (a veces toda ayuda es poca):

• Tener en cuenta que el histórico del sistema se limpia automáticamente con las opciones de limpieza del sistema (GO CLEANUP), por omisión solo conserva los últimos 15 días.

Otra forma de controlar los trabajos es utilizar mi utilidad HSTJOBLOG.

Caja de busqueda en el blog

He añadido una caja de Google en el blog para facilitaros la búsqueda de temas en el blog.

Espero que os sea útil

Someter trabajos batch

Para entender como el sistema somete un trabajo, explicaré cual es el procedimiento básico que utiliza el OS400.Para someter un trabajo utilizamos el mandato SBMJOB, indicando en el parámetro CMD el programa, o mandato, que queremos ejecutar, grabando una entrada en la cola de trabajo:

• Es conveniente indicar un nombre de trabajo (JOB) que nos ayude a controlarlo, ya que por omisión utilizara el valor *JOBD, o sea utilizara el nombre de la descripción de trabajo para todos los trabajos que sometamos sin nombre.
  
• El trabajo ira a la cola de trabajo (JOBQ) que este especificada en el SBMJOB, por omisión tiene *JOBD que nos indica que cogerá el valor de la cola de trabajo especificada en la descripción de trabajo, indicada en el parámetro JOBD.
  
• El parámetro JOBD nos indica la descripción de trabajo que utilizará, por omisión tiene el valor *USRPRF, este nos indica que cogerá el valor de la descripción de trabajo del usuario que esta sometiendo el trabajo. Esto se define en el perfil del usuario (DSPUSRPRF parámetro JOBD).
• El valor del parámetro JOBD(*USRPRF) puede forzarse para tener otro valor, al usar el parámetro USER del SBMJOB (por omisión *CURRENT), que indica que usara otro usuario para ejecutar el trabajo, evidentemente hemos de estar autorizados al perfil de usuario a utilizar ya que puede suponer un agujero de seguridad.
• Podemos definir la prioridad que tendrá nuestro trabajo en la cola de trabajos (JOBPTY) y/o en la cola de salida (OUTPTY). Por omisión utiliza el valor *JOBD recuperando este valor de la descripción de trabajo que habitualmente es 5. Podemos indicarle otro valor que puede ir de 1 (alta prioridad) a 9 (baja prioridad), de todas formas tenemos un limite que esta indicado en el parámetro PTYLMT de nuestro perfil de usuario y que por omisión es 3.
• Con el parámetro OUTQ definimos a que cola de salida irán los listados que genere nuestro trabajo, por omisión es *CURRENT con lo que utiliza la cola de salida que tienen asignada el trabajo desde donde se ejecuta el SBMJOB.
• Otro parámetro muy importante es INLLIBL (Initial library list) donde indicaremos en que bibliotecas y en que orden el sistema operativo debe buscar los objetos (programas, archivos, áreas de datos, etc..) que se utilicen en el trabajo. Por omisión tiene el valor *CURRENT y por tanto la lista de bibliotecas sera la misma que la del trabajo desde donde se ejecuta el SBMJOB. Otro valor que puede tener el parámetro INLLIBL, y muy recomendable utilizar, es *JOBD que utilizara la lista de bibliotecas definida en la descripción de trabajo que utilicemos para someter el trabajo.
• El parámetro RTGDTA (Routing data) es importante para asignar los atributos de ejecución del trabajo, esta relacionado con las entradas de direccionamiento que explicaré en un próximo articulo.
  
• Después vendrían los parámetros relacionados con el log del trabajo: LOG, LOGCLPGM, LOGOUTPUT, JOBMSGQMX. Todos ellos tienen por omisión *JOBD. Habitualmente para que un trabajo deje rastro para que podamos ver los que se ha ejecutado es utilizando los valores LOG(4 00 *SECLVL) LOGCLPGM(*YES).

Para el resto de parámetros y valores os recomiendo leer con más calma la ayuda del propio mandato SBMJOB (SBMJOB + F4+F1+F2, F14 para imprimirla) para entrar en más detalle.

Para mucha más información:
Gestión de Trabajos en el IBM iSeries InformationCenter
Manual de IBM iSeries Systems management and Work management