Bienvenidos a Iseries Venezuela

Las mejores prácticas, recursos, tips, enlaces, videos y artículos para informáticos relacionados con el Iseries y el As/400 lenguajes de programación RPG, ILE RPG y SQL.

The best practices, resources, tips, links, videoes and articles for computer related to the Iseries and the As/400 languages of programming RPG, ILE RPG and SQL.

jueves, 21 de octubre de 2010

Colas de Datos


    











Una cola de datos es similar a un archivo de base de datos sobre el cual se puede escribir o leer un registro. Cada dato de entrada en la cola es similar a un registro. Otro programa o muchos programas pueden leer entradas anteriores grabadas en la cola, similar a la lectura de registros en un archivo.

Una entrada a la cola de datos no tiene descripción externa (dds) es un string de bytes.  Las colas de dato son diseñadas para facilitar la comunicación entre programas. Supongamos que un cliente realiza un pago con la tarjeta de crédito y el banco debe aprobar el pago. Al pasar la tarjeta de crédito por el punto de venta, la ráfaga (string de datos de la tarjeta) es enviada a una data queue que es leída a su vez por un programa autorizador encargado de “desglosar” la información recibida en el string y determinar si el cliente está o no autorizado a realizar la compra con ese monto.

Puedes tener un programa enviando entradas a la cola de datos y docenas de programa activos simultáneamente que leen la entrada tan rápido como es posible. Como cada entrada en la cola es removida de la cola una vez que ha sido leída, no tienes que preocuparte de que otro programa lea la misma información. Continuando con el ejemplo del pago con la tarjeta de crédito, una vez que uno de los procesos autorizadores captura la data de la tarjeta de crédito de un cliente en un punto de venta, cualquier otro proceso autorizador no podrá capturar los datos de ese cliente sino que capturará los datos de otro cliente que haya sido grabado en la cola para hacer el mismo proceso de verificación del consumo.

El as400 tiene dos API, encargadas de grabar el string de datos en la cola de datos y de leerlos. Una vez que el string de datos es leído la data es “desalojada” de la cola en espera de la grabación de la próxima ráfaga de datos.

Las Api son: QSNDDTAQ para grabar data en la cola  y QRCVDTAQ para recibir o leer la data grabada en la cola.

Un ejemplo del código para el programa que graba el registro en la cola:

       CALL 'QSNDDTAQ'             90
       PARM 'DTQ_PMC' P1DTAQ 10  (nombre de la cola)
       PARM '*LIBL'   P1DLIB 10  (librería de la cola)
       PARM 8         P1LEN   50 (longitud de la data)
       PARM           P1RC       (data)

Estos programas (emisor y receptor de data) pueden iniciarse asociados al inicio de un subsistema del Iseries y dejarlo ejecutándose permanentemente en un lazo DOWhile con una condición que nunca se cumplirá. Para finalizar los programa se “tumba” el subsistema en el que se están ejecutando. Como generalmente las colas de datos se asocian a procesos nocturnos que requieren un tiempo de mantenimiento , y de arranque en la madrugada, puede resultar necesario “atar” la ejecución de estos programas receptores de data al inicio y finalización de un subsistema en el Iseries.

  CALL 'QRCVDTAQ'             9192
  PARM 'DTQ_PMC' P1DTAQ 10    (nombre de la cola)   
  PARM '*LIBL'   P1DLIB 10    (Liberia de la cola ) 
  PARM           P1LEN   50   (longitud de la data) 
  PARM           P1RC         (data) 
  PARM -1        P1WAIT  50   (Tiempo de espera para revisar la cola. Cuando es negativo, se espera un tiempo infinito y cuando es mayor a cero se refiere a los segundos de espera.)

Para crear una cola de datos el comando es:

CRTDTAQ  si quieres hacer pruebas del funcionamiento de la cola de datos, puedes escribir el programa que graba y luego el comando DMPOBJ al ejecutar el programa que lee la cola de datos, otro DMPOBJ arroja la data que queda en la cola. Con un programa CLP puedes ejecutar estos comandos y verificar lo que estas grabando y leyendo.

Los datos de la cola pueden ser eliminados con el comando QCLRDTAQ
Las colas de datos pueden tener una clave de ordenamiento permitiendo que la data vaya entrando en un orden FIFO o LIFO, dependiendo de los requerimientos funcionales. Estos parámetros de ordenamiento son opcionales.

Para mayor información de este tema pueden ir al siguiente enlace de IBM



Autor: Ing. Liliana Suárez.


Si te pareció interesante el artículo reenvíalo a un amigo, haciendo click en el sobrecito que está al final del artículo. El conocimiento es valioso, compártelo.

martes, 5 de octubre de 2010

Siete Tips para levantar Información








Siete Tips para Levantar Información.


1.-Pide los manuales, pero no te quedes con eso.
Algunas Instituciones tienen manuales de usuario, manuales del Técnicos del Sistema, manuales del negocio y manuales de normas y procedimientos. Puedes terminar ahogándote en manuales sin llegar a ninguna conclusión. Recuerda pedir información sobre las bases de datos y las relaciones de los archivos.


2.- Comienza a utilizar las aplicaciones actuales de los usuarios.
Aunque te suministren manuales, solicita entrada a la aplicación en un ambiente de desarrollo. Comienza sencillamente a probarlas y a introducir información como cualquier usuario principiante. Es importante que veas cómo funciona la aplicación. Es distinta la teoría a la práctica. Si no es posible que entres a la aplicación en un ambiente de prueba, solicita una cita con un usuario que domine la aplicación para que puedas ver como funciona.

3.-Solicita apoyo a la gente de Organización y Métodos o Control de Procesos.
Recuerda que necesitas gente que certifique tu trabajo. Si haces partícipe a los demás de lo que estás haciendo se sentirán parte de tu proyecto y será más fácil que quieran avalar tu trabajo. Cuando la gente se siente excluida es poco probable que quieran ponerse de tu parte cuando así lo requieras.

4.-Realiza una Bitácora diaria con tus actividades y las dudas sin resolver. Prepara un plan de ataque para cubrir los “vacíos” de información que has detectado.

Si dejas las dudas para el final, posiblemente debas rediseñar los procesos cuando te des cuenta de que omitiste información importante para que la solución que tú propones funcione.

5.-Redacta una minuta de cada reunión que tengas y envíala por correo solicitando la aprobación de los puntos discutidos.

Algunas instituciones permiten grabar la reunión. Puedes utilizar tu celular o un Mp3/4 para grabarla y pasar el audio al resto de los involucrados. Siempre dejar por escrito los acuerdos alcanzados. Aunque como desarrolladores tengamos flojera de escribir la minuta. Recuerda que quien escribe la minuta “se apropia” de la reunión y asume el liderazgo.


6.-Define el alcance de tu solución y colócala por escrito.

Si no dejas bien claro lo que tu propuesta soluciona y LO QUE NO SOLUCIONA comienzan a salir nuevas solicitudes durante el desarrollo del proceso que hacen que el proyecto se vuelva interminable.

7.-Presenta entregas parciales que simulen “en vivo” el funcionamiento de tu solución.
NO esperes hasta el final para tener todo completo y mostrar algo. Las “demo”  te permiten ajustar los diseños de los procesos y darle al usuario final la idea clara de cómo se verá la aplicación. Puedes hacer una secuencia de pantallas una tras otra que, aunque no actualicen nada, le darán una idea al usuario de cuanto has comprendido el proceso. Además te ayudara a definir el alcance de tu proyecto.
Cuando sea el momento de certificar, el proceso ya no será una sorpresa y no dudaran de acelerar la aprobación del proyecto.


Para la próxima entrega, tips para el desarrollo de Software en RPG.

En este enlace puedes descargarte un E-book para crear presentaciones interactivas con Power Point.




Si te pareció interesante el artículo reenvíalo a un amigo, haciendo click en el sobrecito que está al final del artículo. El conocimiento es valioso, compártelo.



Autor: Ing. Liliana Suárez