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, 26 de abril de 2012

PROGRAMAS DE SERVICIO- ILE_RPG - Primera Parte










Lo que en ILE se llama Programa de Servicio ha sido concebido en principio, para codificar, en un mismo programa, las utilidades de uso común por parte de los demás programas del sistema. La ventaja de este sistema centralizado es que todas las  versiones y actualizaciones de las utilidades son mucho mas sencillas de controlar.

Un programa de servicio en su concepto fundamental esta constituido por un conjunto de subprocedures que son declarados en el programa. El programa de servicio típico no tiene cuerpo principal. Se coloca en la hoja ‘H’ la plabra clave *NOMAIN para que el sistema operativo entienda que el contenido del código contiene declaraciones y programación de subprocedures.

Por ejemplo las clásicas utilidades desarrolladas en  programas o rutinas en RPG tradicional se han desarrollado tales como:

“Monto Escrito” (para escribir en letras una cantidad en número),
“Días laborables”
“Encriptamiento/Desencriptamiento”
“Impresión de Chequeras”

Pueden ser colocados en un solo programa de servicio como un subprocedure cada uno.

Cada Subprocedure debe tener la declaración de su prototipo PR para los parámetros de entrada y sus respectivos PI para esos mismos parámetros. Sin embargo, la declaración de los PR y PI se realizan en distintas partes del programa.

La declaración de Prototipos o PR permite al sistema operativo crear un punto de entrada o ENTRY POINT de acceso al programa de servicio  por cada PR declarado.
Esto significa que, el subprocedure que tiene un PR o prototipo asociado, puede ser el proceso arranque de un conjunto de programas enlazados y además puede ser invocado por programas y módulos externos.

Sin la declaración del Prototipo PR,  el subprocedure sería solo de uso local dentro del programa que esta declarado y no podría ser accedido por otros programas o módulos. Es importante aclarar esto puesto que muchos programadores no entienden por qué hay que utilizar PR y PI es decir, declarar los parámetros de entrada "dos veces" para cada subprocedure (es un tema mas extenso para una próxima vez).

En el RPG tradicional no existía la posibilidad de multiples ENTRY_POINT para un programa. El RPG tiene un solo conjunto de parámetros de entrada definidos.


En un programa de servicio cada subprocedure puede ser llamado en forma independiente aún cuando este declarado en el mismo programa. Por tanto, hay múltiples puntos de entradas ( o grupo de parámetros de acceso) por la cual se puede acceder al programa de servicio.

Un programa de servicio sin cuerpo principal - como es este caso-no puede ser invocado a través de un CALL, solo se pueden invocar los subprocedures que están codificados internamente.


La declaración de los prototipos de los subprocedures se coloca al principio del programa, uno tras otro. Es decir,  se declara el prototipo de “Monto Escrito”, seguidamente el prototipo de “Dias laborales” y luego el prototipo de “Encriptamiento” , etc, y al culminar con los prototipos se declaran seguidamente cada subprocedures con su código interno correspondiente y su PI.

El comando para crear un programa de servicio es CRTSRVPGM.


En  próximas entregas, continuaremos detallando el tema de los programas de servicio.



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


Publicado por: Ing. Liliana Suárez

martes, 3 de abril de 2012

5 W y 1 H para el Diseño de Sistemas de Información
















A lo largo del tiempo se han desarrollado varios métodos, sistemas y estrategias para desarrollar sistemas de información,  que va desde las metodologías Top-Down, Bottom-Up, hasta los modelos estructurados e iterativos.

Independiente de la metodología que elijas para diseñar sistemas de información, la clave para el diseño de sistemas de información es la identificación de los procesos.

Una vez que se han identificado los procesos, es necesario contestar las  5 W y 1 H , para cada proceso diseñado, es decir las  cinco preguntas que los periodistas de los medios de comunicación deben responder cuando redactan una noticia para obtener la historia completa sobre algún evento.

Estas 5 W y 1 H son:


What à ¿Qué?
Where à ¿Dónde?
When à  ¿Cuándo?
Who  à  ¿Quién?
Why? à ¿Por qué?
How? à ¿Cómo?


Aplicando estas interrogantes a cada proceso tenemos lo siguiente:

¿Qué resultado se desea obtener?
Describimos el resultado detallado de lo que deseamos alcanzar

¿Dónde debe ser implementado este proceso?
Esto se refiere principalmente a dispositivos (móviles o no), en 
un   servidor dedicado, en un main frame, en un servidor remoto, etc.

¿Cuándo debe ejecutarse e instalarse?
            La frecuencia de ejecución: diaria, mensual, semanal, etc. 
        Las  condiciones preexistentes que deben existir para que se 
        ejecute (luego de que x proceso finalice..etc)

¿Quién debe tener acceso?
Establecemos las jerarquías de acceso al proceso para establecer la permisología necesaria que garantice la integridad de la información

¿Por qué es necesario?
Establecemos la necesidad de desarrollar el proceso y las necesidades de información que esta cubriendo para así justificar el desarrollo del mismo.

¿Cómo debe ser elaborado?

En este punto decidimos las estrategias y tácticas que vamos a emplear para el desarrollo del sistema y el control del avance del proceso.

Cabe destacar que, se puede aplicar este método iterativamente para cada respuesta que hemos dado anteriormente a cada pregunta.

Por ejemplo, dentro de la pregunta ¿Quién debe tener acceso? Una vez dada la respuesta correspondiente podemos preguntar: ¿Qué?, ¿Quién?,¿Dónde? , ¿Cuándo?, ¿Por qué? ¿Cómo?

Este procedimiento ayuda a concretar el proyecto y a la vez evaluar la factibilidad de lo que estamos planteándonos. A veces hay maravillosas ideas que no es posible llevar a cabo, bien sea por lo recursos materiales, o por costos, personas o tiempo. Cuando hacemos estas preguntas “aterrizamos” las ideas al punto que descartamos aquello que a la larga no va a ser posible y nos hace perder tiempo y dinero.


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


Publicado por: Ing. Liliana Suárez