Vuelco de Spool a archivos de base de datos AS400en forma autom., usando Colas de Datos

Conozca cómo producir un vuelco de spool a archivos de base de datos en forma automática, usando COLAS DE DATOS.

Normalmente nos referimos a los archivos de spool como salidas aún no impresas que se encuentran almacenadas dentro de colas de salida (objetos de tipo *OUTQ). Esta afirmación no es errónea, pero parte de ella no es exactamente cierta. Las colas de salida constituyen una organización lógica de los archivos de spool, porque realmente estos elementos están almacenados dentro de la biblioteca QSPL.

Este comportamiento debe considerarse, porque si se necesita manipular (salvar, transferir, etc.) de alguna manera la información de los archivos de spool generados en el sistema, debe convertir los archivos de spool en objetos que posteriormente serán salvados, convertidos, transferidos como cualquier otro archivo.

Las colas de datos son una herramienta del OS/400 que permite automatizar este vuelco de spool a archivos de base de datos, sin necesidad de trabajar manualmente con el comando CPYSPLF. Cuando se necesitan transformaciones masivas de spool en archivos, por ejemplo, para salvarlo, o implementar un sistema tipo COLD, este tip propone la solución.

Introducción: Salvar o manipular contenido de un archivo de spool

Los archivos de spool están físicamente almacenados como miembros dentro de objetos de tipo *FILE, atributo PF-DTA, en la biblioteca del sistema QSPL. Dentro de estos archivos de QSPL, las salidas impresas aparecen sin un formato comprensible y sin poder distinguir un archivo de spool de otro. Las colas de salida, en realidad, contienen las direcciones donde el spool está almacenado. Por lo tanto, los objetos de tipo *OUTQ permiten organizar el spool desde un punto de vista lógico. Ej: colas de salida por usuario, por impresora o cola de salida de información confidencial (sueldos). Este es el motivo por el cual al salvar, una cola de salida, no son salvados los archivos de spool que están dentro de ella.

Para poder salvar, transferir, o manipular contenido de archivos de spool, es necesario convertirlos en miembros de un *FILE PF-DTA pero creado por nosotros. De esta forma, realizando un backup del objeto en cuestión, se salvarían los archivos de spool.

Los pasos necesarios para convertir un archivo de spool en un miembro de un objeto *FILE con atributo PF-DTA fueron especificados en Notas técnicas de AS/400 - Tips en detalle nro 4 - Cómo salvar y restaurar spool. Como se podrá notar en el mencionado tip, los pasos a ejecutar son sencillos, pero poco prácticos si se necesitan realizar para varios archivos de spool.

En las próximas secciones se analizará la creación de un programa que automáticamente convierta los archivos de spool de una determinada cola de salida, conforme ingresan a la misma, en miembros de un archivo físico de datos. En este esquema, los objetos de tipo *DTAQ o Colas de datos desempeñan un importante papel.

Desde ya, esta puede ser una buena solución para implementar el backup del spool, o de una parte importante del mismo, pero cualquier otra aplicación que requiera un vuelco masivo de archivos de spool en archivos de datos pueden utilizar este mismo mecanismo. (Ej. un sistema de almacenamiento óptico, transferencias a PC, etc.)

Colas de datos: Introducción

Las colas de datos son objetos de tipo *DTAQ que pueden crearse en cualquier biblioteca y pueden ser utilizadas para transferir datos entre programas que se ejecutan dentro del mismo job o en distintos trabajos. A través de estos objetos es posible generar esquemas donde uno o varios jobs hacen un requerimiento almacenándolo dentro de una cola de datos, y un trabajo receptor toma cada una de las peticiones y las procesa. El envío y la recepción de entradas a colas de datos se realiza a través de programas del sistema operativo llamados API's (Application Programming Interface): QSNDDTAQ y QRCVDTAQ respectivamente. El siguiente esquema muestra el uso general de las API's dentro de los programas:

Para crear colas de datos se utiliza el comando CRTDTAQ. Las colas de datos tienen diferentes atributos, entre ellos el parámetro Longitud máxima de entrada (palabra clave MAXLEN). Las entradas que se almacenan dentro de una cola de datos no tienen un formato específico, sólo poseen longitud máxima indicada en el momento de la creación de este objeto. Es importante notar que PROGA y también PROGB deben "estar de acuerdo" en cómo se organiza la información dentro de la entrada. Ejemplo: si se crea una cola de datos de longitud 100, se puede organizar la entrada de la siguiente manera: posición 1 a 6 el número de cliente y posición 7 a 36 el nombre del cliente y así hasta completar las 100.

Asociación entre colas de salida (*OUTQ) y colas de datos (*DTAQ)

Existe una interesante relación que puede establecerse entre los objetos de tipo *OUTQ y los objetos de tipo *DTAQ. Cuando se crea una cola de salida, en los parámetros adicionales, se puede visualizar el parámetro Cola de datos (palabra clave DTAQ). Si en este parámetro se especifica el nombre de una cola de datos creada anteriormente, cada vez que un archivo de spool en estado RDY ingrese a la cola de salida, se genera automáticamente una entrada en la cola de datos. La entrada almacenada contiene el nombre completo del archivo de spool. Un programa que lee y procesa las entradas de la cola de datos puede convertir el archivo de spool (cuyo nombre está mencionado en cada entrada) en un miembro de un archivo de base de datos. El siguiente gráfico muestra los objetos involucrados en esta relación:

Observar en el esquema anterior, que el envío de las entradas hacia las colas de datos, o sea la llamada a la API QSNDDTAQ se realiza de manera implícita por la relación establecida entre la cola de salida y la cola de datos.

El programa CONVERSOR, además de copiar el archivo de spool como miembro de un archivo de base de datos, también puede encargarse de depositarlo como un objeto más en un determinado directorio, con extensión ".txt" y especificando la página de códigos a utilizar en la conversión. Esto puede realizarlo utilizando el comando CPYTOSTMF (ver flechas rojas). De esta manera, los datos transferidos estarán disponibles como "stream files" en el directorio del IFS que se haya seleccionado como destino de la copia. Esta sería también la manera de automatizar la copia de archivos de spool como archivos con extensión ".txt". Manualmente se puede realizar desde Operations Navigator, haciendo "dragging" de un archivo de spool hacia el escritorio de la PC.

Implementación del proceso de conversión

Como se menciona en el último párrafo de la sección anterior, la invocación a la API QSNDDTAQ es consecuencia de la relación entre la cola de salida y la cola de datos. El formato de la entrada no es definido por esta implementación, sino que está determinado y proporcionado por IBM de la manera siguiente:

Las sentencias que componen el programa CL CONVERSOR son las siguientes (los números en rojo corresponden a explicaciones sobre las sentencias):

Observaciones:

1. Invocación a la API QRCVDTAQ. Las llamadas a las API's deben respetar el formato con el que fueron definidas, es decir, orden y cantidad de parámetros, tipo y longitud de cada uno de ellos. En el caso particular de QRCVDTAQ los parámetros son:

• Cola de datos desde la cual se lee (*CHAR 10).
• Biblioteca de la cola de datos (*CHAR 10).
• Longitud de la entrada (*DEC (5 0)).
• Entrada (*CHAR, la longitud para este ejemplo es 128).
• Tiempo de espera. Especifica la cantidad de segundos que el programa QRCVDTAQ espera por una entrada. El valor "0" indica "no esperar", un valor mayor expresa la cantidad de segundos a esperar, y el valor "-1" es esperar indefinidamente (*DEC (5 0)).

Los dos primeros parámetros pueden ser constantes, los restantes no.

Luego de la llamada a QRCVDTAQ, la variable &ENTRADA contiene los datos de un archivo de spool a procesar.

2. Las sentencias CHGVAR almacenan en las diferentes variables, los datos del archivo de spool que están contenidos en la variable &ENTRADA, respetando el formato expresado en la tabla anterior.

3. Se traduce de binario a caracteres la información correspondiente al número de archivo de spool dentro del job.

4. Dentro de la variable &MIEMBRO se "arma" el nombre que tendrá el miembro de archivo de base de datos que contendrá el archivo de spool ya convertido.

5. El mandato CPYSPLF es el encargado de convertir el archivo de spool a un miembro de un archivo de base de datos. El objeto *FILE PF-DTA que se menciona (QGPL/CONTENEDOR) debe estar creado con anterioridad. El valor *FCFC en el parámetro Caracteres de control (palabra clave CTLCHAR) da la posibilidad futura de volver a bajar el miembro como archivo de spool, sin que pierda su formato.

En este punto del programa se podría agregar el comando CPYTOSTMF (Copy to stream file). El mandato toma un miembro de un archivo de base de datos (previamente generado por CPYSPLF) y lo deposita en un determinado directorio que debe estar previamente creado. También es posible seleccionar la página de códigos del archivo que se generará en el IFS.

6. Luego que el archivo de spool ya fue convertido a miembro, puede ser eliminado de la cola de salida. Observar que la lectura de la entrada desde la cola de datos no elimina el archivo de spool en la cola de salida.

7. A través del mandato CHGPFM, se asocia al miembro de archivo de base de datos una descripción que asista al usuario en la identificación del spool.

Para poder implementar en forma exitosa esta aplicación es necesario cumplir con los siguientes pasos en el orden indicado:

1 Crear una cola de datos: CRTDTAQ DTAQ(QGPL/COLADATOS) MAXLEN(128) . La longitud de la entrada para colas de datos que se vinculan con colas de salida debe ser al menos de 128.

2 Crear una cola de salida y vincularla con la cola de datos creada en el paso 1:

CRTOUTQ OUTQ(QGPL/AGUARDAR) DTAQ(QGPL/COLADATOS)

3 Crear un archivo físico sin formato de registro:

CRTPF FILE(QGPL/CONTENEDOR) RCDLEN(133) MAXMBRS(*NOMAX)

Observar que la longitud de registro debe ser la del archivo de spool más ancho que se quiera almacenar más uno. Esta posición extra se utilizará para guardar el caracter de control en caso de realizar el comando CPYSPLF con el parámetro CTLCHAR establecido en *FCFC. El máximo de miembros (parámetro MAXMBRS) debe estar en *NOMAX, porque el default de "1" no permitiría agregar al archivo más de un miembro.

4 Crear un directorio en el IFS:

Este paso es necesario si se agrega en el programa el comando CPYTOSTMF que toma miembros de un archivo físico de datos y los convierte en archivos continuos. Puede crearse desde pantalla verde o a través del Operations Navigator.

CRTDIR DIR('/spool')

5 Crear el fuente y compilar el programa CL

6 Considerar el sometimiento planificado del programa. Puede agregarse una entrada planificada con el comando WRKJOBSCDE o incorporar en un subsistema un trabajo de arranque automático con el comando ADDAJE. Tener en cuenta la frecuencia de apagado del sistema.

Una vez completados estos pasos, la información convertida queda disponible para salvarla, transferirla, etc. Puede utilizarse el comando SAVOBJ sobre el archivo CONTENEDOR para salvar los miembros convertidos o pueden procesarse con alguna herramienta los archivos de texto depositados en el directorio /spool.

Para tener en cuenta...

• Una misma cola de datos puede estar vinculada con más de una cola de salida.
• Más de un trabajo puede recibir datos de una misma cola de datos.
• Los comandos existentes para trabajar con colas de datos son WRKDTAQ, CRTDTAQ y DLTDTAQ. Además de las API's ya nombradas, existe también QCLRDTAQ que se utiliza para eliminar las entradas presentes en una cola de datos (parámetros cola de datos y biblioteca).
• Vaciar las entradas de una cola de datos con la API QCLRDTAQ no reduce el tamaño del objeto a su valor mínimo, por lo tanto se aconseja utilizar los comandos DLTDTAQ y CRTDTAQ.
• A partir de V4R5 existen dos nuevos parámetros en el comando CRTDTAQ: Tamaño de la cola y Reclamación automática. El parámetro Tamaño de la cola permite especificar un número de entradas inicial (por default 16 entradas) y un máximo de tamaño que el objeto *DTAQ puede alcanzar. Si el parámetro Reclamación automática es establecido en *YES, el almacenamiento asignado para la cola de datos es reclamado cuando el objeto *DTAQ está vacío.
• Una vez que el miembro fue procesado, puede eliminarse del archivo de base de datos con el comando RMVM. Esto no debería realizarse si el objetivo es salvar el archivo CONTENEDOR.
• Es posible también automatizar el camino inverso volviendo a generar los archivos en el spool. El comando CPYFRMSTMF convierte un archivo ".txt" en un miembro de un archivo de base de datos.
• Si el trabajo que ejecuta el programa convertidor permanece activo por muchos días, considerar la posibilidad de someterlo especificando en el parámetro adicional Anotaciones de mensajes con el valor Nivel establecido en "0". Cada entrada procesada genera varios mensajes en la joblog.

  ---

Copyright Teknoda S.A.