Sumisión de peticiones por ficheros

Pre-requisitos

Para que el lanzamiento de peticiones batch pueda realizarse por medio de ficheros, es necesario:

    Que el parámetro general Uso de ficheros batch sea Sí en los parámetros del servidor batch.

    Que el parámetro EXTBATCH sea Sí. Este parámetro, que pertenece al grupo SUP, puede definirse a nivel del dossier y del usuario. Es posible prohibir globalmente el lanzamiento de peticiones batch de este modo para un dossier dado, concediendo, en caso de ser necesario, una excepción a los usuarios designados.

Los ficheros de petición (extensión req)

El lanzamiento de una petición batch puede realizarse depositando un fichero de extensión .job en el repertorio dedicado a estos ficheros. Este fichero de tipo ascii, estructuradas en línea terminadas por <CR> o <CR><LF>, cada línea que define el valor de un parámetro con la forma:

PARÁMETRO=VALOR

Ciertos parámetros son obligatorios e identifican el contexto de ejecución de la petición. Hay otros parámetros que dependen de la petición que va a lanzar; su nombre corresponde al nombre de los parámetros definidos en la pantalla asociada al lanzamiento de la petición. En ciertos casos se define un cuadro de parámetros en la pantalla; entonces se parametriza la sintaxis (índice)=VALOR, índice

Con el fin de facilitar la creación de un fichero de este tipo, es posible lanzar la petición desde la aplicación, marcando la casilla modelo en la pantalla de lanzamiento de las peticiones. Si se hace esto, se crea un fichero con la lista completa de los parámetros de lanzamiento y se crea un valor en el repertorio de lanzamiento. Este fichero se crea con el nombre de la petición y la extensión .mod.

En el cuadro que aparece a continuación, aparece en nombre de los parámetros obligatorios y su definición.

PARÁMETRO	DEFINICIÓN
DOSSIER	El código del dossier sobre el que se lanza la petición
UTIL	El código de uso de conexión al dossier
CONTRASEÑA	La clave encriptada del usuario
GRP	El grupo de peticiones (si se lanza un grupo)
TAREA	La petición (si se lanza una petición)
FECHA	La fecha de inicio (en formato AAAAMMDD)
HORA	La hora de lanzamiento (en formato HHMM)

Hay que tener en cuenta que los valores del parámetros se dan sin separadores de ningún tipo, y que es posible poner líneas de comentarios prefijados por el caracter #. De este modo, se podrá meter en el fichero de petición:

         # Parámetros obligatorios

         DOSSIER=DEMO

         DATE=20020614

        …

       # Parámetros complementarios

       PARAM(1)=TEST

        PARAM(2)=ABC

Cinemática de tratamiento de los ficheros de petición

El servidor batch inspecciona a intervalos regulares el contenido del directorio dedicado a los ficheros de petición. En el momento de la inspección, lee los ficheros presentes en el repertorio tomándoles en órden de la clasificación ascii. De este modo, se aconseja denominar estos ficheros con una raíz fija y un número secuencial con una longitud fija. Por ejemplo, REQ000001.req, REQ0000002.req…

En el momento del tratamiento de cada fichero, se crean ficheros sucesivamente en los distintos directorios definidos por los parámetrs del servidor batch. Estos ficheros se definen a continuación:

ETAPA DE TRATAMIENTO	FICHEROS ACTUALIZADOS
Presentar una solicitud de tratamiento batch	Creación del fichero xxxxx.job por un proceso externo en el directorio dedicado.
El servidor batch tiene en cuenta la solicitud y actualiza su tabla de peticiones a lanzar	El fichero xxxxx.job se redenomina comoxxxxx.req (y se desplaza si los directorios no son los mismos)
El servidor decta un error en el fichero de parámetros (contraseña incorrecta, código de tarea desconocido...)	El fichero xxxxx.job se redenomina comoxxxxx.old (y se desplaza si los directorios no son los mismos). Se crea un fichero xxxxx.sta en el repertorio dedicado. Contiene un código de error que permite saber qué fichero de entrada era incorrecto (ver formato del fichero a continuación).
La petición está en curso de ejecucuón tras el lanzamiento del servidor batch.	El fichero xxxxx.req se redenomina comoxxxxx.old (y se desplaza si los directorios no son los mismos). Se crea un fichero xxxxx.run en el repertorio dedicado.
Se termina la petición (de forma correcta o con un error)	el fichero xxxxx.run se borra y se crea un fichero xxxxx.sta en el directorio dedicado: este fichero contiene un estatus de retorno (ver formato del fichero a continuación).
Presenta una solicitud de interrupción de la petición batch (a la espera del lanzamiento o ya lanzado)	Creación del fichero xxxxx.kil por un proceso externo en el directorio dedicado.
Tener un cuenta la solicitud de interrupción (si la petición no se ha lanzado aún)	El fichero xxxxx.req (o el fichero xxxxx.job si aún no se había tenido en cuenta) se redenomina xxxxx.old. Se crea un fichero xxxxx.sta en el repertorio dedicado. Contiene un código de error que permite saber que la petición se ha interrumpido sin haberse lanzado. Se borra el l fichero xxxxx.kil .
Tener un cuenta la solicitud de interrupción (si la petición no se ha terminado aún)	La petición se interrumpe en killadx, después se crea el fichero xxxxx.sta en el directorio dedicado, con un código de error que permite saber que se ha interrumpido la petición. Se borran los ficheros xxxxx.kil y xxxxx.run .
Teniendo en cuenta las prioridades de ejecución o de parón del servidor batch; la petición no ha podido lanzarse en los plazos previstos (petición fuera de plazo)	No se ha lanzado la peticón, pero el ficheroxxxxx.req (el fichero xxxxx.joben caso contrario) se redenomina como xxxx.old y se desplaza s es necesario. Se crea un fichero xxxxx.sta en el repertorio dedicado. Contiene un código de error que permite saber que la petición no se ha podid lanzar.

Hay que tener en cuenta que la existencia del fichero xxxxx.run no significa necesariamente que la petición en cuestión se repita. De hecho, si se detiene el servidor batch sin que las peticiones de vuelta no han parado, los ficheros xxxxx.run correspondientes existen siempre incluso cuando la petición ha terminado el tratamiento. En este caso, el fichero xxxxx.sta no se creará más. Por otro lado, cuando el servidor batch se lanza de nuevo, el fichero xxxxx.run se borray se crea un fichero xxxxx.sta con un estatus particular.

El nombre de peticiones batch en curso de tratamiento no puede deducirse forzosamente del número de ficheros xxxxx.run presentes en el repertorio dedicado.

Descripción de los ficheros XXX.sta, XXX.run, XXX.kil

Estos ficheros son ficheros ascii, códigos en ascii 8 bits, presentes en distintos repertorios, según la parametrización:

• El fichero .kil puede estar vacío o contener un comentario que se retomará en el fichero de extensión .sta
• El fichero .run contiene una línea conforme a la estructura definida a continuación; las informaciones indicadas como númer de la petición, la fecha y la hora de inicio, y el códgio de la tarea (las otras informaciones se completan con 0 o espacios)
• El fichero .sta contiene una línea cuyo formato se define a continuación, y todos los campos están indicados.

La estructura de la línea única contenida en los ficheros .run y .sta es la siguiente:

• La línea se compone de 8 campos de longitud fija, con separadores (el caracter dos puntos ‘ :’).
• La longitud total es de entre 154 y 155 caracteres

El esquema exacto es el siguiente:

Nº estado	Nº petición	Fecha y hora de inicio	Fecha y hora de fin	Código de dossier	Código de usuario	Código de la tarea	Mensaje en claro	Fin de línea
NNNNN	NNNNNNNN	AAAAMMDDHHMMSS	AAAAMMDDHHMMSS	DDDDDDDDDD	UUUUU	TTTTTTTTTT	XXXXXXXXXXXXXXXXXX	<CR> o <CR><LF>
5 cifras	(8 cifras)	(14 cifras)	(14 cifras)	(10 caracteres)	(5 caracteres)	(10 caracteres)	(80 caracteres)	( 1 ó 2 octetos)

La zona de mensaje permite explicitar el código de error si es necesario. Se almacena con una longitud fija de 80 caracteres (el mensaje se completa con espacios si es necesario).

El número de petición se almacena en 8 caracteres, precedidos por ceros si es necesario. Este número permite conocer el nombre del fichero de traza generado en el momento de la ejecución de la petición. Este fichero se denomina RQT NNNNNNNN.tra (NNNNNNNN es el número de petición en 8 caracteres). Lo encontramos en el sub directorio TRA del dossier SERVX3. Hay que tener en cuenta que este númoer puede ser nulo en ciertos casos de error, cuando no ha podido lanzarse ninguna petición.

El código de la tarea correspondiente a la tarea o al encadenamiento de tareas lanzadas, tal y como se muestra en la tabla de tareas o de los encadenamientos.

El código de estado, en 5 caracteres numéricos, permite conocer el resultado de la ejecución. La primera cifra determina el resultado global de la ejecución, las cifras siguientes aportan los datos complementarios. Cuando la petición se termina sin errores y sin avisos, el código de error que se obtiene es igual a 00000. El detalle de los códigos se especifica a continuación:

Valor del código de error en 5 cifras				Mensaje en claro
Primera cifra	Significado	Complemento	Significado
0	Fin normal del tratamiento	0000	Sin aviso	PETICIÓN TERMINADA
		NNNN	Con NNNN avisos en la traza (9999 si 9999 o más)	PETICIÓN TERMINADA CON AVISOS
1	Fin de tratamiento por error	0000	Error no especificado (por ejemplo si GOK=-1 y no hay más información suplementaria)	PETICIÓN TERMINADA CON UN ERROR DESCONOCIDO
		1NNN	Error no NNNN del motor adonix (mensaje M)	FIN POR ERROR ADONIX: M
		2000	Error de bloqueo (GOK=0)	ERROR DE BLOQUEO
		3NNN	Error lógico de tratamiento con: NNN = valor variable GERRBATCH, M = valor variable GMESSBATCH	PETICIÓN TERMINADA CON UN ERROR M
			Nota: las variables GERRBATCH y GMESSBATCH permiten a los programadores calificar de forma precisa las condiciones del error; esto es posile en una tarea específica, pero también en una tarea estándar por los puntos de entrada. El valor de la variable GERRBATCH influye en el seguimiento del tratamient, cuando este está integrado en un grupo de tareas. De hecho, si la variable GERRBATCH es estrictamente inferior a 100, la tarea que sigue se lanzará a pesar del error. Si, por otro lado GERRBATCH tiene un valor superior o igual, las tareas siguientes del grupo no se lanzarán.
2	Tratamiento no lanzado	1000	La tarea se ha programado para una hora dada, pero no ha podido lanzarse en los plazos previstos.	PLAZO SOBREPASADO
		2000	Tarea inexistente	TTT TAREA INEXISTENTE
		3000	Habilitación (no especificada)	TRATAMIENTO NO LANZADO POR PROBLEMA DE HABILITACIÓN NO ESPECIFICADA
		3100	Habilitación (usuarioU desconocido)	USUARIO U DESCONOCIDO
		3200	Habilitación (contraseña incorrecta para ese usuario U)	Contraseña incorrecta para ese usuario U)
		3300	Habilitación (rechazo por punto de entrada)	TRATAMIENTO NO LANZADO POR HABILITACIÓN RECHAZADA POR PUNTO DE ENTRADA
		3400	Habilitación (nivel N de la tarea prohibida al usuario U insuficiente)	NIVEL DE ACCESO N NO AUTORIZADO AL USUARIOU
		3500	Habilitación (función F no autorizado al usuario U)	F FUNCIÓN NO AUTORIZADA AL USUARIOU
		4NNN	Paso en modo mono imposible (NNN usuario en curso)	PASO EN MODO MONO IMPOSIBLE POR NNN HABER USUARIOS CONECTADOS
		5000	Tratamiento T inexistente	TRATAMIENTO T INEXISTENTE
3	Tratamiento detenido	0000	Tratamiento detenido, razón desconocida (por ejemplo si un proceso distinto al servidor batch ha detenido la petición)	PETICIÓN INTERRUMPIDA (RAZÓN DESCONOCIDA)
		1000	Por fichero de extensión .kil, con el mensaje M	PETICIÓN INTERRUMPIDA POR U DEBIDO A M
			Nota: en caso de un kill por fichero, el código de usuario puede vaciarse. De hecho, el sistema intenta saber, a partir de la identidad del usuario que ha creado el fichero, si le corresponde un código de usuario adonix o no. Esta búsqueda puede no tener resultado según los sistemas de explotación empleados.
		2000	Por la gestión de las tareas del usuario U : el mensaje capturado es M	PETICIÓN INTERRUMPIDA POR U DEBIDO A M
		3000	Por el servidor batch car time-out	TRATAMIENTO INTERRUMPIDO POR EL SERVIDOR MOTIVO=SUPERACIÓN DEL TIEMPO PREDETERMINADO

Notas

Hay que tener en cuenta que, en el marco de la diferenciación por modelos de las tareas batch (modelo GTRAITE), el usuario dispone de las variables siguientes, a las que se puede acceder desde las tareas específicas, o en las tareas estándar por medio de puntos de entrada:

• La variable GOK es un estatus actualizado de los lanzamientos de la tarea. Si no hay ningún problema, tiene valor 1, 0 en caso de bloqueo, -1 en un error grave de otro tipo y 2 en un error grave que implica al servidor. Esta variable la generan las tareas estándar: Si no tiene valor 1 al final de un tratamiento batch, la tarea aparece en estado Error en vigilancia de las tareas; en este caso, si la tarea forma parte de un grupo de tareas, las tareas siguientes se bloquean y no se lanzarán.
• La variable GERREUR sólo se adjudica a un valor no nulo en caso de error en la ejecución de una instrucción (es el número de error que corresponde a una excepción tratada por la instrucción Onerrgo). Si esta variable es no nula al final de la tarea, el estado de la tarea se coloca en Abortado en la vigilancia de tareas, y las tareas que siguen, si la tarea forma parte de un grupo, se bloquean.
• La variable GERRTRACEC permite contar el número de líneas de traza de error creadas por la tarea. También la generan las tareas estándar. Al ser positiva, la tarea se coloca en Error en la tarea de vigilancia, sin por ello bloquear el encadenamiento de las tareas siguientes en un grupo. De hecho se trata del descuento de un número de líneas de error que se suponen sin malas consecuencias.
• La variable GERBATCH es una variable numérica suplementaria, que permite dar un código de error que depende de la tarea si se considera que la tarea no se ha terminado correctamente (esto es independiente del hecho de que las líneas de traza de error hayan sido generadas o no). Si el valor de GERRBATCH es inferior a 100, se considera que se trata de un estatus de error benigno. Si, por otro lado, el valor de GERRBATCH es superior o igual a 100, el estado de la tarea en la función de supervisión de las tareas pasa a Erreur al final de la ejecución, y si la tarea forma parte de un grupo, el encadenamiento de las tareas siguientes se interrumpe. Esta variable ha sido creada para permitir una gestión de error específico por un punto de entrada.
• La variable GMESSBATCH es una variable alfanumérica que permite dar un mensaje de error complementario. Este mensaje se inserta en el contenido del fichero de extensión .sta si se produce un error.

Excepto por un error de coherencia en el lanzamiento, las tareas batch de la aplicacin tienen en cuenta en todos los casos que los errores encontrados son benignos y simplemente actualizan la traza incrementando GERRTRACE. Esto significa que cualquier error grave que deba interrumpir el tratamiento, debe ser tratado de forma especfica, por medio de puntos de entrada, dando a GERRBATCHóí un valor superior a 100.

Descripción del fichero servidor.tra

Este fichero, presente en el sub directorio TRA del directorio SERVX3, contiene la traza del servidor. La estructura de las líneas es conforme a la de un fichero de traza clásica (encabezado normalizado, y el estatus numérico en 5 caracteres). Cada línea se compone de un texte precedido por un número (este número se ve precedido a su vez por el caracter < si se considera que se trata de un error, por = se trata de un aviso).

Los números de estado siguiente existen (están precedidos por 4 y 5 por razones de continuidad de numeración con los estados precedentes). Hay que tener en cuenta que los estados que empiezan por 4 son estados graves que no deberían ocurrir en un trabajo normal (problemas de actualización, de gestión de tareas, de bloqueo del servidor batch) y pueden proceder de problemas de sistema, bien por una mala instalación, bien por específicos. Los estados que empiezan por 5 son, estados normales de la actividad del servidor batch:

ERRORES GRAVES DE COHERENCIA DEL SERVIDOR
Situación	Explicación	Texto
41000	Desincronizción de tarea	ERROR DE DESINCRONIZACIÓN DE TAREA
42000	Problema de acceso a la tabla de tareas	ERROR DE ACCESO A LA TABLA DE TAREAS
43000	Número de petición inexistente	ERROR DE PETICIÓN INEXISTENTE
44000	Problema de acceso a la tabla de parámetros batch

 

MENSAJES DE EXPLOTACIÓN NORMALES DEL SERVIDOR
50000	Arranque del servidor	ARRANQUE DEL SERVIDOR BATCH
51000	Activación de petición (proceso id P)	ACTIVACIÓN PETICIÓN PID=P
52NNN	Error adonix NNN en el momento de arrancar el servidor (mensaje de error = M)	ERROR EN EL ARRANQUE DEL SERVIDOR M
53000	Error distinto del arranque del servidor	ERROR INDETERMINADO EN EL ARRANQUE DEL SERVIDOR
54000	Lanzamiento del servidor cuando aún está activo	EL SERVIDOR ESTÁ YA ACTIVO
55000	Desactivación del servidor

Descripción de los ficheros RQTNNNNNNNN.tra

Estos ficheros, presentes en el sub directorio TRA del directorio SERVX3, contiene la traza asociada a la petición en sí misma. La estructura de las líneas es conforme a la de un fichero de traza clásica (encabezado normalizado, y el estatus numérico en 5 caracteres). Cada línea se compone de un texte precedido por un número (este número se ve precedido a su vez por el caracter < si se considera que se trata de un error o de un aviso). Estos ficheros pueden ser leídos directamente desde el gestionador de peticiones mediante el botón derecho / Lectura traza.

Pasada la línea de cabecera, la primera línea de un fichero de este tipo se presenta en forma de una línea con el formato siguiente (integra el estado Activación de petición definida a continuación):

=51000 NNNNNNNN JJ/MM/AA hh :mm :ss Activación petición(51000)

(NNNNNNNN representa aquí el número de la tarea)

Las líneas de traza clásica de la tarea siguen esta primera línea (si el tratamiento en cuestión no se lanza en batch, estas líneas se escribirán en un fichero de traza clásico FNNNNN.tra en el directorio TRA del dossier de lanzamiento). Después, excepto si la tarea se ha detenido de forma brusca (por un killadx, por ejemplo), se encontrará una línea final de estructura idéntica, pero en la que el número es conforme al estado de fin correcto (0000) o de error (1NNNN) descrito a continuación.

Tablas utilizadas

105:Las tablas siguientes se utilizan en la función:

• Tabla ABATRQT
• Tabla ABATTAC
• Tabla ABATGRP