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.

Sunday, September 6, 2009

CONTROL DE PROCESOS










Control de Procesos.

Un proceso tiene la misión de producir un resultado único, tangible, medible y distinguible del resultado que otro proceso pueda producir.

Los programas, módulo y sistemas que se alimentan o actualizan una determinada información y que conllevan a producir un impacto específico dentro de una secuencia de ejecución corresponden generalmente a un proceso que los engloba.

Es importante, para los analistas, establecer en un contexto mas general las relaciones de los programas módulos y sistema que han sido desarrollados en la empresa.

El Arquitecto de Procesos en una empresa tiene una gran responsabilidad puesto que debe determinar el alcance del proceso y los mecanismos de ejecución, reverso, backup,
Re-ejecución y contingencia que deben disponerse para cada proceso.

En un contexto de ISERIES si bien se ha desarrollado recientemente el concepto de módulos en ILE y de Procedures estáticos y dinámicos, esto no corresponde en ningún modo al concepto de PROCESO, corresponde a la importación desde otras plataformas, de lo que se llama programación modular. Esto le ha dado una nueva visión a la eficacia en el desarrollo de programas mas allá de la programación estructurada tradicional.

El proceso se define por la FUNCIONALIDAD es decir por el resultado que un conjunto de ejecutables producen basados en LOS PROCESOS DEL NEGOCIO.

En el contexto del ISERIES es, en general, difícil conseguir un control de procesos efectivo. Lo tradicional ha sido generar una serie de Backups en varias partes de los procesos para asegurar el reproceso en caso de caída del sistema, error de ejecución o falla operativa. Esto hace que el operador tenga que intervenir y en ocasiones tomar decisiones mas allá de su conocimiento y alcance de sus funciones.

Es necesario establecer archivos de control de procesos o mecanismos de control a través de áreas de datos (data-areas) que permitan al sistema automáticamente retomar el proceso donde había quedado si la intervención recurrente del operador. El monitoreos de errores tanto en los CLP como en el RPG, es un mecanismo muy efectivo que hay que aprovechar para tomar una decisión en forma automática y no solo para evitar a los ojos del usuario que se vea la falla de programación.


Podemos definir un archivo de control con los siguientes campos:

Nombre del proceso
Secuencia
Status actual
Ultima fecha de ejecución
Resultado de la ejecución (exitosa, incompleta, fallida)
Acción a tomar en caso de falla.
Siguiente secuencia o proceso a ejecutar en caso de falla.
Siguiente secuencia a ejecutar si todo okey.
Plan de contingencia operativo
Plan de contingencia procedimental.

Si construimos un CLP de procesos, a manera de ejemplo,

PGM

Verificar el status del PROCESO 1. (call programa rpg parm(siguiente etiqueta a ejecutar))



Goto etiqueta a ejecutar (Label 1, o Label 2 o la que corresponda, según lo que haya devuelto el progrma RPG)

Label 1 : PROCESO 1

Verificar el status del proceso 1. (call programa rpg parm(siguiente etiqueta a ejecutar))

Verificar el status del proceso 2. (call programa rpg parm(siguiente etiqueta a ejecutar))

Label 2: PROCESO 2

Verificar el status del proceso 2. (call programa rpg parm(siguiente etiqueta a ejecutar))





ENDPGM


Se verifican los status del proceso antes y después de ejecutarse porque no sabemos si se trata de un reproceso por una falla anterior. Esto nos permite saber si hay que re-ejecutar el proceso o si por el contrario la falla fue posterior y podemos saltarnos ese paso esta vez. En el registro de control de procesos, que es el archivo de control que presenté anteriormente debe residir la información veraz que permita establecer una acción correcta en forma automática.

Hay muchas maneras de establecer mecanismos de control. Lo importante es tener
Claro el alcance y la definición de los procesos y además los mecanismos automáticos y procedimentales que deben implementarse en caso de una situación imprevista.


Si te pareció interesante, reenvialo 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

Saturday, September 5, 2009

ARCHIVO DDM









Archivos DDM. (Data Distributed Management)


Un archivo DDM es un archivo que contiene información sobre otro archivo que reside en un servidor Iseries remoto. Esto es particularmente útil para traernos información desde el ISERIES de producción al ISERIES de Desarrollo o para traernos el fuente correcto a modificar o la data que necesitamos para hacer pruebas.

Por ejemplo, supongamos que queremos copiar data o un fuente desde un ISERIES hacia nuestro ISERIES.

Primero, definimos un DDM en el ISERIES donde estamos trabajando especificando en los parámetros del DDM, el nombre del sistema (SNA) y el nombre del archivo que se encuentra en el ISERIES remoto. (Esto si queremos copiar los archivo vía SNA. También puede crearse el DDM con la dirección IP del ISERIES remoto)

Una manera rápida para saber el nombre del sistema de un ISERIES es entrar en el ISERIES y hacer un DSPJOB en la línea de comandos de su sesión interactiva y en la parte superior derecha de la pantalla conseguirá un código que generalmente comienza con la letra ‘S’, por ejemplo: S1029093.
Una vez que tiene el nombre del sistema remoto aplicando el procedimiento descrito, (en el ISERIES remoto) proceda a realizar el siguiente comando:(en el ISERIES local)

CRTDDMF FILE(MILIBRERIA/DDM1)
RMTFILE(LIBRERIA/ARCHIVO)
RMTLOCNAME(‘S1029344’ *SNA)



MILIBRERIA se refiere a la librería donde estamos creando el DDM en nuestro ISERIES de trabajo. (local)
DDM1 puede ser cualquier nombre.
RMTFILE especifica la librería y el archivo que queremos traernos a nuestro equipo.
RMTLOCNAME: especifica el nombre del sistema remoto.

Podemos hacer un CPYF en nuestro ISERIES local para traernos la data desde el ISERIES remoto. Supongamos que queremos guardar el archivo remoto en nuestro ISERIES local en la Librería denominada: LDESTINO y que el objeto copiado se llame: OBJETOC

CPYF FROMFILE(MILIBRERIA/DDM1) TOFILE(LDESTINO/OBJETOC) MBROPT(*REPLACE)
CRTFILE(*YES)


De esta manera traemos a nuestro ISERIES data almacenada en El ISERIES remoto.

Podemos hacer CHGDDMF para cambiar la DDM y traernos otro archivo de otras librerías o incluso de otros ISERIES.

Podemos trabajar con la dirección IP como en este comando:

CRTDDMF FILE(LIBRERIA/DDM2)
RMTFILE(PAGOS)
RMTLOCNAME('9.5.36.17' *IP) PORT(5021)


El archivo remoto puede ser un archivo fuente como QCLSRC, QRPGSRC, o un archivo de data.

Para mayor información pueden remitirse al link de IBM:

http://publib.boulder.ibm.com/iseries/v5r2/ic2928/index.htm?info/cl/crtddmf.htm



Si te pareció interesante, reenvialo 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