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.

martes, 28 de diciembre de 2010

Bitácoras.



                         









En algunas organizaciones se requieren aplicaciones que sirvan de bitácora para que el usuario pueda plasmar en ellas comentarios, opiniones y seguimientos que no siempre son posibles de estandarizar. Por ejemplo, en una clínica, las descripciones de las dolencias no pueden estandarizarse puesto que depende de la edad del paciente, el historial médico y las complicaciones previstas e imprevistas que conforman un cuadro médico único e imposible de codificar en términos computacionales. En estos casos, podemos proveer alguna aplicación sencilla en el AS/400 que además de guardar el responsable del registro de la bitácora, la fecha y hora de registro y el texto descriptivo del cuadro médico o de la situación emergente que se está describiendo, podemos incluir algunos campos a manera de cuestionario para asegurarnos de que el usuario cargue información significativa que permita a cualquier supervisor de la organización tener una idea mas clara de lo que sucede con el caso en seguimiento.

Un ejemplo de esto podría se la inclusión de campos como:
Días adicionales en la clínica.
Monto adicional por día de estadía.
Cambio de dieta. (si o no)
Cambio de tratamiento.(si o no)
Cambio de enfermera (si o no)
Tratamientos adicionales (Si o no).

Estas y otras preguntas tipo cuestionario corto, pueden dar una información resumida de los aspectos relevantes en relación al paciente aún cuando el texto descriptivo contenga términos médicos o abreviaturas que aunque para el médico son vitales, para otras áreas administrativas de la organización que realizan seguimiento del caso puede resultar engorroso y de poca utilidad operativa. La idea además de cubrir un requerimiento no estandarizable, es asegurarnos de que el usuario información significativa para la organización entera que operativamente funciona como un todo integrado que recibe y envía información continuamente.

Este ejemplo es exportable para cualquier otro tipo de organización que requiere llevar bitácoras en línea con información no estándar ni codificable desde el punto de vista informático.


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.

jueves, 16 de diciembre de 2010

SQL y el JOIN



                        






En el manejo del SQL el empleo del JOIN es muy importante para realizar búsquedas en la base de datos y sobretodo para comprobar la integridad de la data.
Existen tres tipos de JOIN: INNER JOIN, LEFT JOIN, RIGHT JOIN.
Vamos a ver con un ejemplo como funcionan estos JOIN.

Supongamos que tenemos dos bases de datos:

La base de datos EMPLEADOS que contiene la siguiente información.
Clave = Id, Nacionalidad

Id. 5886825
Nombre= Pedro Perez
Nacionalidad = USA

Id. 66677889
Nombre = Juan Rodríguez
Nacionalidad = MEX

La base de Datos SUELDOS que contiene la siguiente información:
Clave = ID, NACIONALIDAD, DEPARTAMENTO

Id. 5886825
Nacionalidad = USA
Sueldo = 5000,00
Departamento = Contabilidad.

Id. 444333221
Nacionalidad = BOL
Sueldo = 8000,00
Departamento = Finanzas


En este momento Juan Rodríguez no ha sido asignado a ningún departamento.

La denominación Archivo1 se lo asignamos a la Base de Datos  EMPLEADOS
La denominación Archivo2 se lo asignamos a la base de Datos SUELDOS


Vamos a ver cual es el resultado de la consulta cuando trabajamos con INNER JOIN:


SELECT Archivo1.ID, Archivo2.ID, Archivo1.NOMBRE, Archivo2.SUELDO INNER JOIN SUELDOS Archivo2 ON  Archivo1.ID = Archivo2.ID and Archivo1.NACIONALIDAD = Archivo2.NACIONALIDAD.

El resultado de la búsqueda es:

5.886.825, 5.886.825, Pedro Perez. 5000

Esto corresponde en la imagen al área de color amarillo de la figura, donde están los empleados que se encuentran en ambas bases de datos.


Vamos a ver cual es el resultado de la consulta cuando trabajamos con LEFT JOIN:

SELECT Archivo1.ID, Archivo2.ID, Archivo1.NOMBRE, Archivo2.SUELDO LEFT JOIN SUELDOS Archivo2 ON  Archivo1.ID = Archivo2.ID and Archivo1.NACIONALIDAD = Archivo2.NACIONALIDAD.

66.677.889, NULL, Juan Rodríguez. NULL

Esto corresponde en la imagen al área de color azul de la figura, donde están los empleados que se encuentran SOLO en la base de datos: EMPLEADOS.


Vamos a ver cual es el resultado de la consulta cuando trabajamos con RIGHT JOIN:

SELECT Archivo1.ID, Archivo2.ID, Archivo1.NOMBRE, Archivo2.SUELDO RIGHT JOIN SUELDOS Archivo2 ON  Archivo1.ID = Archivo2.ID and Archivo1.NACIONALIDAD = Archivo2.NACIONALIDAD.

NULL, 444333221, NULL, 8000

Esto corresponde en la imagen al área de color verde de la figura, donde están los empleados que se encuentran SOLO en la base de datos: SUELDOS. Este último resultado nos está señalando que no hay integridad en la Base de Datos y debemos revisar que está ocurriendo.



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.



jueves, 2 de diciembre de 2010

Haciendo Fácil lo Difícil











Una estrategia de programación muy vieja pero muy buena.

Cuando realizamos programas de actualización que permiten ingresar, modificar y eliminar información, podemos vernos atrapados en lazos dentro de lazos dentro de lazos. Siguiendo el Estándar de IBM en el manejo de las teclas de función, usamos el  F3 para salir y F12 para regresar a la pantalla anterior, (en todas las pantallas) y para navegar de una pantalla a otra dentro del programa hacemos While que a su vez tienen internamente otros While que tienen otros While, etc. Todos estos while finalizan por la misma condición *in03 o también *in12.

Si utilizamos un CASE como el MAIN del programa, se nos facilita el proceso. Este CASE  según el nivel de ejecución (mas interno o mas externo) direcciona a la rutina ha ser ejecutada sin necesidad de tener lazos anidados.

Algoritmo de Ejemplo.

                     NIVEL = 1
                     DOW NIVEL <> 0
                       CASE
                        NIVEL = 1      EXSR pantalla1
                        NIVEL = 2      EXSR pantalla 2
                       ENDCAS
                     ENDDO
                    *INLR = *ON

BEGSR PANTALLA1
Muestra pantalla1
Valida pantalla1
Si F12 or F3 entonces Nivel = 0
Sino
   Si no hay error nivel = 2
   Fin-SI
  Fin_SI
ENDSR

BEGSR PANTALLA2
Muestra pantalla2
Valida pantalla2
Si F12 entonces Nivel = 1
Sino
Si F3 entonces Nivel = 0
 Sino
   Si no hay error Procesar
      Fin-SI
      Fin-SI
Fin-SI



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.

jueves, 25 de noviembre de 2010

Integración de Opciones.










                                           

                                                      

 (Hacer Click para agrandar la imágen)

Así como en el mundo de la electrónica cada vez los dispositivos son más pequeños y tienen integradas múltiples funciones, en el mundo del desarrollo de software cada vez se desarrollan programas integrados que permiten la navegación, consulta y actualización en la misma aplicación. Tradicionalmente se realizaban (y se realizan) un menú de consulta, un menú de mantenimiento y un menú de impresión. Por lo menos tres menús básicos. Cada menú tiene varias opciones según el acceso a la información. Por ejemplo clasificando la data: por nombre, por fecha, por monto, por responsable, por código, etc.

Puedes ver a la izquierda de la imagen que acompaña a este artículo, un ejemplo de menú con varias opciones. A la izquierda se trata de acceder en la misma pantalla por distintas claves de acceso la misma información. Cuando en la pantalla de la izquierda tenemos varias opciones por nombre, cedula, caso, etc, en la pantalla de la derecha tenemos una sola pantalla que permite el acceso por cedula, nombre, caso, habitación, etc. El usuario solo tuvo que ingresar por una opción del menú y es la pantalla de entrada (landing screen) la que debe garantizar el acceso múltiple.

Hay que tener en cuenta varias cosas cuando se sustituye la forma de desarrollo de varias opciones en un menú por aplicaciones integradas.

Deben realizarse una revisión o una reingeniería (dependiendo del caso) del manejo de la seguridad de acceso. Hay usuarios que solo pueden consultar, otros que pueden actualizar data y otros que pueden hacer todo. En un programa integrado, las autorizaciones deben ser manejadas por algún sistema previamente desarrollado en la institución, antes de desarrollar programas integrados. Es posible que actualmente, cada opción del menú (pantalla izquierda de la imagen) tenga un nivel de autoridad y el menú se genera en forma dinámica suprimiendo o agregando opciones al menú de cada usuario según su jerarquía de acceso.

Los programas deben ser desarrollados en forma modular y/o estructurada. Se generan muchas líneas de código en un solo programa que puede resultar pesado de mantener por la extensión del código. En el enfoque de un menú con varias opciones, son pequeños programas dispersos con pocas líneas de código que resultan generalmente más sencillos de mantener, aunque se requiera varios niveles de menú para que el usuario consiga la información que busca.

Debe realizarse el programa bajo un estándar corporativo de programación.
El mantenimiento de este único programa o de este grupo de programas puede resultar engorroso si el programa crece demasiado y no se ha desarrollado bajo un estándar de programación accesible a todos los programadores.

La prueba del programa debe ser exhaustiva y además realizada por el usuario durante varios días para asegurar que se tomaron en cuenta todas las condiciones posibles.





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.

domingo, 7 de noviembre de 2010

OVERRIDE de Archivos en ILE-RPG


                                                                                     







Tradicionalmente se realiza el Override de archivos en un programa CLP que luego llama a un  programa RPG.

Este RPG entonces realiza las operaciones pertinentes y al terminar la ejecución del programa RPG entonces el programa CLP debe realizar, en algún momento,  un DLTOVR(*ALL) para continuar con el resto de los comandos.

Ahora es posible realizar con ILE-RPG y con ILE-RPG Free el override del archivo dentro del programa RPG en la hoja F junto con la declaración del archivo.

Se utilizan las Keywords: EXTFILE y EXTMBR para especificar el archivo y el miembro sobre el cual se hace override.
Si se omite el EXTMBR el sistema operativo asume el primer miembro del archivo.

En el ejemplo que tienen a continuación, declaro un archivo con un EXTFILE cuyo contenido está en un campo constante que indica la librería (LDMED43) y el archivo (IN102L10X)

fIN102L10x uf   e           k disk    rename(IN102r:in102rx)
f                                     USROPN               
f                                     Extfile(ARCHIVO102)  

d*Declaración de constantes.
d ARCHIVO102      c                   const('LDMED43/IN102L10X')

El archivo debe ser USROPN para que funcione este sistema.
Al Principio del programa haces un OPEN IN102L10X y antes de Finalizar
Realizas el CLOSE IN102L10X

Con este procedimiento ya no es necesario realizar un CLP que lo único que hace es el override a los archivos de los programas en RPG, que son invocados posteriormente.



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.

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

lunes, 20 de septiembre de 2010

Mejores Practicas en RPG: Estructura de Datos


   









1.- Uso Del Extname en la declaración de estructuras de datos:

En el ejemplo se utiliza para acumular totales en los campos de un archivo
Sin tener que renombrar campo a campo.

 Antes: (RPG 3)

     E                    SER        35 11 2             
     I***
     IFP002R
     I              FP2C01                          SER,1
     I              FP2C02                          SER,2
     I              FP2C03                          SER,3
     I              FP2C04                          SER,4
     I              FP2C05                          SER,5
     I              FP2C06                          SER,6
     I              FP2C07                          SER,7
     I              FP2C08                          SER,8
     I              FP2C09                          SER,9
------------------------------------------------
Después: (Rpg4, Free)

     dDsFp002F       e ds                  Extname(Fp002F) Prefix(DS_)
     d Servicios                     11p 2 Dim(35)
     d                                     Overlay(DsFp002F:130)  

 //* 130 es la posición de comienzo delcampo FP2C01 que indica el archivo. Se puede ver con dspffd.

2.- No utilices tablas a tiempo de compilación al final del programa.

Antes:

Tablas al final del programa luego de la Hoja C
**
1Lunes
2Martes
3Miercoles


Después.


     dSemana     Ds
     dLunes                                  10   Inz(‘Lunes’)
     dMartes                                 10  Inz(‘Martes’)
     dMiercoles                             10  Inz(‘Miercoles’)
     d Dias_Semana                     10   Dim(3)
     d                                                  Overlay(Semana)  

3.-La Estructura de Datos para Validar una fecha, es un recurso muy útil.
Esa antigua manera de validar si el día del mes es mayor a 31, si el año es bisiesto,
o si el mes está entre 1 y 12 quedó atrás.

     d                 ds
     dFecVal                    1     10
     dAnoVal                   1      4  0 Inz(0)
     dSep1                        5      5    Inz('-')
     dMesVal                   6      7  0 Inz(0)
     dSep2                        8      8    Inz('-')
     dDiaVal                     9     10  0 Inz(0)
     d*

       Diaval   = Dia;  (dia= dia de La fecha a validar)
       Mesval  = Mes;  (Mes de La fecha a validar)
       Anoval = Ano;  (Ano de La fecha a validar)

Test(DE) *ISO Fecval;
  If %error;
     Dsp_error = 'Fecha Invalida';   
   Endif;


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.

sábado, 4 de septiembre de 2010

Integración de Consultas













    Tradicionalmente, en especial en aquellos software que ofrecían soluciones integradas a las organizaciones, se disponía de un menú principal para “navegar” en la consultas del sistema. El primer menú tenía un número significativo de opciones que a su vez nos remitían a submenú o consultas que extraían la información según una clave de acceso en particular. Se tenían innumerables programas que desplegaban la información en pantalla bien sea por nombre, apellido, cédula, código de clientes, producto, etc.

   Cuando revisamos el código fuente del RPG observamos en muchos casos que se trata del acceso al mismo archivo pero realizando una búsqueda (chain) con una clave distinta en cada ocasión, mostrando al final la misma pantalla en todos los casos.

    El inconveniente que trae este sistema de programación es que al requerirse un cambio en las pantallas de consultas hay que cambiar la misma pantalla (por lo menos en su formato básico) en todos los programas donde se requiere desplegar el campo que antes no se desplegaba.

    Actualmente se realizan estos desarrollos con una única pantalla de entrada que tiene todos los parámetros posibles por los que el usuario puede realizar la consulta. El campo que contenga un valor “válido” será utilizado en ese único programa como elemento de búsqueda, para luego desplegar la pantalla con los valores que correspondan. Con la inclusión del SQL dinámico embebido en la programación RPG puede construirse la consulta “a tiempo de ejecución” para extraer los registros que cumplan con la condición de selección especificada por el usuario. El uso de SQL dinámico nos evita la creación de lógicos y por ende, agiliza el tiempo de respuesta en el procesamiento de los archivos.





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.





domingo, 22 de agosto de 2010

Cómo abrir una sesión FTP en Batch







En varias ocasiones me han preguntado vía Email, cómo realizar un proceso FTP en BATCH tomando en cuenta que requerimos el usuario y la clave para abrir la sesión FTP.

En esta oportunidad les adjunto tres programas que son útiles para generar comandos FTP batch manejando el tema del usuario y la clave.

La idea es tener un archivo donde se graban los comandos FTP.

En este caso el archivo se llama FTPPAS, es un archivo que no tiene DDS sino que se crea con CRTPF con un largo de 132 posiciones. EL objeto del archivo se crea dinámicamente a tiempo de ejecución en la librería QTEMP. Esto es para no embasurar el disco. Una vez terminado el proceso el sistema operativo elimina el archivo al terminar el job.

El primer programa: PROGRAMA1 es un CLP.

1.-Verifica si existe el archivo FTPPAS en QTEMP, si no existe lo crea
2.-Luego llama a un programa RPG que se encarga de grabar en el archivo FTPPAS, cada comando FTP.

Notaras que la llamada al programa oprpg501 tiene en sus dos parámetros el usuario y la clave respectivamente.

La clave puedes preguntarla por pantalla al usuario, que va a ejecutar esto o tenerlos guardados en una dataara en un archivo, colocarlos en el programa directamente, como tu prefieras.

Existe un comando llamado CHKPWD. A ese comando le pasas el password que el usuario colocó en pantalla y el sistema operativo chequea si en verdad corresponde al password del usuario que está realizando la solicitud en pantalla, si no es así, se monitorea el error y se manda un mensaje de error.
Si no dispones de este comando en tu equipo, en el link al final de este artículo puedes descargar una utilidad que se encarga de realizar esta verificación.


IF COND(&IN03 = '1') THEN(GOTO FIN))


CHKPWD PASSWORD(&PSW) MONMSG
MSGID(CPF2362 CPF2363 CPF2364 CPF0001) EXEC(DO) CHGVAR VAR(&MSG) VALUE('La contraseña ingresada no +
                         corresponde al perfil del usuario')
GOTO LAZO2
ENDDO

FIN: ENDPGM

El tercer parámetro es la dirección IP con la cual se va a realizar la conexión, el cuarto y quinto parámetro es el nombre del archivo de salvar (donde está la data) y la librería del archivo de salvar. En este ejemplo se trata de enviar un SAVF desde un AS/400 hacia un PC.

3.-Por ultimo el programa llama a un CLP el cual se encarga de realizar efectivamente la serie de comandos FTP enviando la data.


El segundo Programa: PROGRAMA2 es un RPG.

Este Programa graba en el archivo FTPPAS y es llamado por el programa anterior.

Resalté en amarillo las instrucciones que interesan. Como puedes ver, arma cada instruccion FTP y hace WRITE al archivo FTPPAS.


El Tercer Programa: PROGRAMA3 es un CLP

Este programa es llamado por el primer programa y ejecuta el comando STRTCPFTP con parámetro la dirección IP.

Veras que se hace un override sobre el FTPPAS y que se crea un nuevo archivo llamado FPPASOUT sobre el cual también se hace override. Este archivo es también un físico sin dds de 132. En este archivo va a quedar un LOG para ti que puedes revisar después para saber si el proceso corrió bien o no. Es un log con todos los mensajes que envía el sistema operativo cada vez que ejecuta un comando FTP y puedes ver si fue satisfactorio o no.

Se crea en QTEMP para no embasurar el sistema. EL FTPPAS sirve como INPUT al comando STRTCPFTP y el FTPPASOUT sirve como output del log de ejecución. Este archivo FTPPASOUT es muy útil si quieres probar el programa interactivo primero y ver si corre bien. Vas mirando con un SQL o con un DSPPFM los mensajes que deja y así te aseguras que el proceso esta funcionando antes de ponerlo en producción como un proceso batch.

Puedes descargar los fuentes mencionados en este link:

http://cid-99e67619d21bbebb.office.live.com/browse.aspx/FTP%20BATCH


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.

jueves, 12 de agosto de 2010

Flujo de eventos para una conexión con socket




        
















(Haz Click para agrandar la imágen)


En la imágen podemos ver el flujo de eventos en una comunicación con Sockets. A continuación describimos las diferentes funciones (comandos) que son invocados dentro del programa RPG para establecer una comunicación entre el programa cliente y el programa servidor.


                                                                            
1.- La function SOCKET() crea un punto de conexión para comunicaciones y regresa un numero entero que representa el descriptor del socket. Un descriptor identifica de manera univoca a un Socket.


2.-Cuando una aplicación tiene un descriptor de socket, esta aplicación  puede asociar un nombre de socket único para ser accesible en la red. Para crear este nombre de red se utiliza bind().


Avisar al sistema operativo de que hemos abierto un socket y queremos que   asocie nuestro programa a dicho socket, se  consigue mediante la función bind(). El sistema todavía no atenderá a las conexiones de clientes, simplemente anota que cuando empiece a hacerlo, tendrá que avisarnos a nosotros. Es en esta llamada cuando se debe indicar el número de servicio al que se quiere atender.


3.-La función listen() indica la disponibilidad de aceptar conexión con  solicitudes de cliente. La funcion listen() debe ser emitida luego de crear una conexión bind() y antes de un accept(). Avisar al sistema de que comience a atender dicha conexión de red se consigue mediante la función listen(). A partir de este momento el sistema operativo anotará la conexión de cualquier cliente para pasárnosla cuando se lo pidamos. Si llegan clientes más rápido de lo que somos capaces de atenderlos, el sistema operativo hace una "cola" con ellos y nos los irá pasando según vayamos pidiéndolo


4.-La función connect() establece una conexión con el servidor


5.-La función Accept()  acepta la conexión con el cliente.  Esta función le indica al sistema operativo que nos dé al siguiente cliente de la cola. Si no hay clientes se quedará bloqueada hasta que algún cliente se conecte.


6.-Una vez establecida la conexión, el cliente y el servidor  pueden seleccionar funciones de transmisión o envío de data como send(), recv(), read(), write()




7.-Cuando un servidor o cliente terminan la conexión deben emitir la función close()           


Bibliografía en la web:

www.Wikipedia.com


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.

domingo, 1 de agosto de 2010

¿Que es un Socket?













                                                                                      (Click en la imagen para agrandarla)

Un Socket es un punto de conexión de comunicaciones que posee un nombre y dirección en una red. Digamos que actua como “un enchufe virtual” que permite el envío y la recepción de data en un entorno de red.

Una forma de conseguir que dos programas se transmitan datos, basada en el protocolo TCP/IP, es la programación de sockets. Un socket no es más que un "canal de comunicación" entre dos programas que corren sobre ordenadores distintos    o incluso en el mismo ordenador.

Desde el punto de vista de programación, un socket no es más que un "archivo" que se abre de una manera especial. Una vez abierto se pueden escribir y leer datos de él con las habituales funciones de read() y write() del lenguaje C. (en RPG se invoca a procedures realizados en C) Hablaremos de todo esto con detalle más adelante.

 Los procesos que usan un socket pueden residir sobre el mismo sistema o en  sistemas diferentes sobre diferentes redes. Los Sockets son útiles porque  permiten
 cambiar la información entre procesos sobre la misma máquina o a través de una red, distribuir el trabajo a la máquina más eficiente, y permite al acceso a datos centralizados fácilmente.. OS/400 soporta sockets de múltiples transportes y protocolos conectados a una red.
 Los Sockets comúnmente son usados para la interacción de cliente/servidor. La configuración de sistema típica coloca al servidor sobre una máquina, con los clientes sobre otras máquinas. Los clientes se unen al servidor, cambian la información, y luego se desconectan.

LA CONEXIÓN

Para poder realizar la conexión entre ambos programas son necesarias varias cosas:
·         Dirección IP del servidor.
·         Servicio que queremos crear / utilizar.


Un servicio es una comunicación a la cual le asignamos un nombre y le asociamos un puerto de conexión.
Nosotros elegimos el número del puerto. Se recomienda elegir números de 7001 en adelante. Cuando abrimos la comunicación en un programa RPG o en C, mediante una instrucción BIND debemos especificar en este comando el nombre del servicio para que mediante este nombre el sistema operativo acceda al número del puerto que definimos en las tablas. En otro tipo de programación en vez del nombre del servicio, se requiere directamente el número de puerto.

 Es a través de este “enchufe” virtual que creamos con el comando ADDSRVTBLE  que hace que nos aparezca la pantalla que está adjunta en este artículo cuando especificamos el servicio y el puerto.
 El programa que reside en la máquina cliente y el programa que reside en el servidor envían y reciben data en forma única. Es decir, no se está mezclando data de otros servidores ni de otros clientes, puesto que los programas que están instalados en ambos equipos abrieron la comunicación con este número de puerto establecido por convención previa en el código de programación.

Si se desea ofrecer otro servicio a otro cliente por este mismo servidor, se declara otro puerto y servicio en la tabla y esos otros  programas de comunicación envían y reciben data a través de este otro servicio.

Para el próximo artículo veremos mas detalles del cliente y el servidor, y los comandos Sockets dentro de los programas.

Si quieren bajar programas que manejan  socket realizados en RPG pueden leer la página de Scott Klement, quien además tiene un excelente tutorial en línea y en PDF accesible tanto para expertos como a neófitos en la materia. La Página es: www.scottklement.com


Bibliografía en la web:




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.