Adefesios en RPG
APIS
Aplicaciones multi-idioma
Apuntadores
Archivos
as400
AS400 Para Principiantes
Base de Datos
Best practices
Better Performance
Botones en RPG
Calidad Profesional
CLP
Colas de Datos
Comandos PC
Cursos
DEBUG en RPG
Desarrollo de Software
Divertidos
EDI
EDI X12
Edward de Bono
el arte de la guerra
FAQS
Fechas en RPG
FRAUDE
FTP
Gerencia de Sistemas
Grupos de activacion
Herramientas Gerenciales
ILE
ilerpg
indicadores
Iseries
JSON
Lista de Códigos de Error
Master Mind
Mejorando el performance
Mejores Prácticas en RPG
micros
Migración
modulos
Monitoreo de Errores
Mouse
OCCUR
pantalla verde
Pantallas
Peores Practicas
Performance
podcast
pointers
Procesos
Programación CL
Ratón
rpg
RPG-FREE
RPGLE
Seguridad
Servidores
Sesion 1 fundamentos de internet
SEU
Sockets
SQL
SQLRPG
Subfiles
subprocedures
Sun Tzu
Tarjetas de Crédito
Tiempos de Respuesta
Tips en RPG
Transfer Control
Triggers
Utilidades
Ventanas moviles
Versiones
videos
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.
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.
Tuesday, April 28, 2009
Mejores Prácticas en RPG. Control Estructurado de Procesos.
Tradicionalmente el cuerpo principal del programa en RPG se conformaba con una serie de lazos anidados que llamaban a distintas rutinas encargadas de validar, calcular, actualizar o generar los archivos de salida.
El aspecto del programa era algo como esto:
Exfmt Fmt01
Dow not(*in03)
|
| Exsr Validar
| /* indicador 99 = On hubo error */
|
| Dow not (*in99) and not (*in03)
| |
| | Exfmt Fmt02
| |
| | If *in06
| | Exsr Valida-Incluir
| | Exsr Graba-Incluir
| | Endif
| |
| | If opcion = 2
| | Exsr Valida-Modificar
| | Exsr Act-Modificar.
| |
| | Endif
| |
| |
| | If opcion = 4
| | Exsr Valida-Eliminar
| | Exsr Act-Eliminar
| | Endif
| |
| |
| | Enddo
|
| Exfmt Fmt01
|
| Enddo
Este es un ejemplo relativamente sencillo con dos lazos anidados. Cuando los procesos requieren una navegación por pantalla mucho mas profunda, podemos tener 3, 4,5 y mas lazos anidados, haciéndose engorroso el mantenimiento del programa y difícil el control y seguimiento del mismo.
Sunday, April 26, 2009
Monitoreo de Errores en RPG (4/4)
Uso del Monitor group
Continuamos con el monitoreo de errores en RPG.
Este es el útimo articulo de una serie de cuatro.Si no has leído los anteriores posiblemente no se te facilite seguir el contenido de esta entrega.
En la versión V5R1 se introduce un Monitor Group: esto te permite monitorear un conjuntos de instrucciones con errores potenciales, en contraposición al chequeo individual de cada una de ellas. Por otra parte es posible monitorear instrucciones que no permite codigo extendido (E).
El concepto funciona similar a un grupo SELECT, y tiene las siguiente estructura:
Comienza el monitoreo con la palabra clave: MONITOR
Monitor
Conjunto de instrucciones en RPG ha se monitoreadas
C READ archivo
C IF
C ...
C Eval a = b(j)+ 4
C ...
C Etc...
// comienza el monitoreo
On-Error codigoerror1 : codigoerror2 :codigoerror3;
// realizar accion
On-Error *FILE;
// realizar accion
On-Error *PROGRAM;
// realizar accion
On-Error *ALL;
// realizar accion
EndMon;
Saturday, April 25, 2009
Monitoreo de Errores en RPG (3/4)
Continuamos con el tema del monitoreo de errores en RPG, esta es la tercera entrega de una serie de cuatro. Es recomendable que leas lo anteriores de esta serie para que se te facilite continuar con el contenido de este artículo.
Hay dos subrutinas para manejar errores en RPG. La rutina de manejo de errores sobre operaciones de archivos (especificada en la palabra clave INFSR) y la rutina para manejar los errores de ejecución en RPG (*PSSR.
En artículos anteriores especificábamos para cada archivo declarado SU respectiva INFDS, y en el código del programa, una vez detectado un error de I/O por medio de un indicador o un código extendido (E) llamábamos explícitamente a la rutina que se encargaría de procesar el error de I/O y enviar el mensaje correspondiente.
En la declaración del archivo podemos especificar a través de la palabra clave
INFSR la rutina que tomará el control del error en caso de que el archivo arroje algún problema de I/O. No será necesario realizar un EXSR explícito sino que el programa automáticamente al detectar un error pasará el control a la rutina especificada en el INFSR.
Por ejemplo:
FARCHIVO1 OF E K DISK KINFDS DS1
F...............................KINFSR SRERROR1
FARCHIVO2 UF E K DISK KINFDS DS2
F...............................KINFSR SRERROR2
Especificamos para el ARCHIVO1 y para el ARCHIVO2, una rutina distinta, SRERROR1 y SRERROR2, respectivamente, aunque puede ser la misma si así lo deseamos, sin embargo la INFDS si debe ser única para cada archivo.
Para manejar los errores de ejecución de RPG tales como índice fuera de rango, división por cero y cosas así se utiliza la rutina *PSSR. Cuando declaramos en la hoja C del programa la rutina *PSSR, el sistema operativo automáticamente dirige el control del error del programa a esa rutina y ejecuta las instrucciones que han sido especificadas por el programador para manipular los mensajes de error o realizar cualquier acción que se requiera.
La rutina *PSSR también puede especificarse en la declaración de archivos en la palabra clave, INFSR de manera que podemos indicarle a RPG que cuando haya problemas de I/O en un archivo se ejecuten los comandos que estén establecidos en la rutina *PSSR.
FARCHIVO1 OF E K DISK KINFDS DS1
F...............................KINFSR *PSSR
FARCHIVO2 UF E K DISK KINFDS DS2
F...............................KINFSR *PSSR
Para determinar el código de error del error para cada archivo vimos en artículos anteriores que se asocia una estructura de datos en el INFDS en la hoja ‘F’ asociada a cada archivo. Para determinar el código de error no asociado a errores de I/O, debemos declarar la SDS que es la estructura de datos de sistema. Algunos manuales la denominan PSDS (Program System Data Structure)
La PSDS tiene el siguiente formato básico:
D SDS
D PROC_NAME *PROC * Procedure name
D PGM_STATUS *STATUS * Status code
D PRV_STATUS 16 20S 0 * Previous status
D LINE_NUM 21 28 * Src list line number
D ROUTINE *ROUTINE * Routine name
D PARMS *PARMS * Num passed parms
Hay más posiciones que nos dan información sobre las condiciones de ejecución del programa que pueden ver en este link: http://faq.midrange.com/data/cache/234.html
Para no hacer tan extenso este artículo colocamos las más usadas y conocidas.
Un ejemplo del código sería el siguiente:
FARCHIVO IF E K DISK
D
...
...
D PSDS SDS
D Procedure *PROC
D Status *STATUS
C
C Read ARCHIVO
C Eval TAB, Z = Valor
...
C Eval LR = *ON
C*
C *PSSR BEGSR
C Status IFEQ 00121
C .....
C* Mensaje de Índice fuera de rango.
c
C RETURN
C ENDIF
C ENDSR
En el Link publicado en este blog titulado Manuales y Documentos RPG, pueden descargar el manual IleRpgReferenceSummaryVersion5, en el primer capitulo: Error Handling está la lista de errores asociados a PSDS distintos a la lista de errores de I/O. Ambas listas están en el mismo capitulo.
Nótese que, en este ejemplo, el archivo no está siendo monitoreado. Si hay un error de I/O, el programa producirá un mensaje de error. Algunos programadores piensan que colocando la rutina *PSSR se monitorea todo, pero no es así porque para el monitoreo errores de I/O de los archivos debemos especificar en su declaración la INFDS y la INFSR.
Puede parecer agobiante el control de errores, por lo que resulta cómodo muchas veces utilizar los indicadores de error en las instrucciones que nos interesa monitorear o trabajar con código extendido (E) con las functions built-in %error y
%status. Sin embargo, cuando surge un problema a tiempo real que debe ser resuelto con carácter de urgencia, la experiencia me dicta que mientras mas detallada y rápidamente tengamos información sobre el error, es mas rápida y efectiva la solución del problema que está requiriendo una atención urgente.
ESPECIFICANDO UN PUNTO DE RETORNO en el ENDSR
El empleo de estas palabras claves es opcional, pero se importante conocer su existencia y uso.
Cuando utilizamos una rutina de error especificada en el INFSR o la rutina *PSSR, puedes indicar al programa en punto de retorno donde deberá continuar la ejecución del programa una vez monitoreado el error. Esto los puedes hacer colocando un keyword especial en el FACTOR 2 del ENDSR de la rutina que monitorea el error. La entrada que coloque acá debe ser de 6 posiciones carácter y puede ser una variable, constante elemento de una tabla o literal.
Si el punto de retorno es un literal, entonces debe estar encerrado en apóstrofos y en mayúsculas. Si se coloca una variable, el valor debe estar ajustado a la izquierda.
Ejemplo en el siguiente código:
C *PSSR BEGSR
C If Error <> 00102
C Eval Divsr = Divsr + 1
C Eval ACCION = '*DETC'
C Else
C Eval ACCION = '*CANCL'
C Endif
C ENDSR ACCION
En el ejemplo, si hay división por cero, se detiene la ejecución del programa, si el error es de otra naturaleza, continúa el procesamiento con una operación de input.
La variable ACCION debe ser de 6 posiciones alfabéticas. También puede colocarse en lugar de la variable, directamente el literal si el punto de retorno fuese siempre el mismo, en este caso, si siempre queremos que se suspenda la ejecución del programa:
ENDSR ‘*CANCL’
Los valores válidos para los puntos de retorno son:
*DETL Continue at the beginning of detail lines.
*GETIN Continue at the get input record routine.
*TOTC Continue at the beginning of total calculations.
*TOTL Continue at the beginning of total lines.
*OFL Continue at the beginning of overflow lines.
*DETC Continue at the beginning of detail calculations.
*CANCL Cancel the processing of the program.
Si no colocas nada, se Retorna el control por defecto al Ile-Rpg. Por ejemplo, si la subrutina fue llamada por un EXSR, el programa regresa a la siguiente instrucción que siguió a la llamada de la rutina.
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
Friday, April 24, 2009
Monitoreo de Errores en RPG: Código de operación extendido. (2/4)
Anteriormente vimos como monitorear errores sobre la operación de un archivo utilizando indicadores de error y una estructura definida con la palabra clave INFDS.
Los indicadores de error no solo se utilizan para monitorear operaciones sobre archivos hay otras operaciones que también admiten monitoreo de error. La tabla de errores de esas operaciones (que no son sobre un archivo) es distinta y requiere el uso de una estructura de datos denominada PSDS que en un artículo previo la aplicamos para determinar quien estaba bloqueando el registro de un archivo. No en este artículo pero si en uno posterior se extenderá la explicación del uso de la estructura PSDS.
Las operaciones en RPG que permiten indicadores de error también permiten un código de operación extendido, utilizando una parámetro ‘E’. La operación CALLP también permite un extensor ‘E’ aunque no permite asociar un indicador de error. Esto provee dos métodos en ILE RPG para manipular errores a tiempo de ejecución. Para una misma operación se utiliza o un indicador de error o un extensor ‘E’ pero no ambos. Es decir, se puede utilizar esto:
RECORDKEY CHAIN(E) FILEREC 90
O esto:
RECORDKEY CHAIN FILEREC 9091
Monitoreo de errores en programas RPG. Primera Parte. (1/4)
En un programa CLP es muy fácil monitorear los mensajes de error. Utilizando el comando MONMSG(códigodeerrror) y especificando el código de error que se requiere monitorear, se puede con facilidad tomar el control del programa enviando el mensaje de error correspondiente y direccionado la ejecución del programa a la instrucción donde se requiere continuar sin que se produzca un mensaje de error en pantalla que incomode al usuario o que coloque en alerta al operador del sistema.
En RPG el asunto es un poco más complicado. Existen tres maneras de monitorear los mensajes de error.
1-La primera de ellas está relacionada con el monitoreo sobre errores producidos en la operación sobre un archivo.
a.- INFDS
b .-Uso de la Extensión (E) en el código de operación.
2-La segunda se relaciona con errores propios de la ejecución de alguna instrucción de RPG
3-La tercera es la más efectiva y sustituye a las anteriores pero está disponible únicamente para RPG IV e ILE-RPG
Monitoreo de Errores de Archivos. (primera parte)
INFDS(NOMBREDS)
La palabra clave INFDS te permite definir, en el programa RPG, el nombre de una estructura de datos que contiene la información asociada con un archivo. El nombre de la estructura de datos que se utilizará para tal fin se especifica en el parámetro de la palabra INFDS. Si INFDS es especificada en más de un archivo, cada estructura de datos asociada debe tener un nombre único.
Una INFDS debe ser definida para cada archivo para recoger la información relacionada con los errores de excepción disponibles para el programa.
La INFDS tiene la siguiente información.
• File Feedback (longitud 80)
• Open Feedback (longitud 160)
• Input/Output Feedback (longitud126)
• Device Specific Feedback (longitude variable)
• Get Attributes Feedback (longitude variable)
Para este artículo vamos a trabajar con el FILE FEEDBACK. La información contenida en las primeras 80 posiciones para monitorear los errores de archivos a tiempo de ejecución es, en general, más que suficiente para extraer la causa del error en el proceso de manipulación del archivo dentro del programa.
Friday, April 17, 2009
El Registro está Bloqueado
A veces tenemos un problema cuando varios usuarios tratan de acceder al mismo registro, al mismo tiempo. ¿Hay alguna manera de saber si el registro está bloqueado sin tener que esperar que el tiempo máximo limite (timeout)?
Cuando un registro esta bloqueado en RPG IV, este permanece bloqueado hasta que uno de los siguientes eventos ocurre:
-El registro es actualizado
-El registro es eliminado
-Otro registro es leido en el archivo
-Un Settl o SetGT es ejecutado contra el archivo
-
El mensaje que nos da el programa cuando vamos al Log de mensajes del Job es algo como esto:
Record 148 in use by job 365563/USER/QPADEV000D.
Esta información es guardada en el Program Status Data Structure SDS, en las posiciones 91-170.
A continuación un pseudocódigo para detectar si el registro está siendo bloqueado y como extraer la información que nos interesa para enviar un mensaje al usuario.
Definimos la Program Status Data Structure
D SDS
D JobName 91 170
* JobName contiene la información del Job que está bloqueando el registro
* El Indicador 99 nos indica si el registro al que queremos acceder está bloqueado.
C Clave Chain Archivo 9899
C if *In99 (* si está bloqueado*)
Buscar la primera ‘/’ del campo JobName
C eval PosInicial = %scan('/' : JobName: 1)
c
** Extraemos la información del campo JobName
c eval Usuario = %subst(JobName:PosInicial + 1)
** Armamos el mensaje de salida
c eval Mensaje = 'El usuario ' + Usuario +
C ' está bloqueando el registro'
** Luego Mostramos por pantalla el Mensaje
C Endif
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
Monday, April 6, 2009
Establecer Relaciones de la Tablas de Datos
Pregunta:
Te comento que estoy ha cargo de un sistema informático en un Centro de Rehabilitación, quiero encontrar la forma de generar un gráfico para determinar las relaciones de los archivos físicos (algo similar a lo que se puede hacer en SQL Server u Oracle) talvez conoces la forma de realizarlo o existe alguna herramienta en el AS400 ?
Saludos. Jaime Maza, Ecuador.
Respuesta:
La mayoria de los programadores o diseñadores no crean base de datos sino una colección de archivos que en ningun momento especifican al AS400 cuales son las relaciones entre ellos. Al crear archivos manualmente via DDS (fisicos, lógicos creados manualmente al compilar el fuente SEU) no hay manera de informarle al DB2 del AS400, cómo es la relación entre ellos.
Existe una herramienta que se llama Erwin para generar las relaciones entre archivos y construir la base de datos en el AS400, pero los archivos deben haber sido diseñados bajo los estándares de modelos relacionales de base de datos.
El DB2 del AS400 controla el cumplimiento de estos estándares.
El procedimiento para generar bases de datos DB2 es:
1.-Modelar en Erwin las base de datos del AS400 desde windows,
2.-Luego esta información generada por Erwin es transferida al AS400,
3.-Finalmente los administradores de la base de datos del AS400 activan, en el AS400 un procedimiento que genera en forma automática una base de datos controlada por el manejador DB2, las tablas son creadas con comandos SQL en el AS400(create table etc) en base a la información recibida desde windows con el modelo Erwin.
Si no estan diseñados de esa manera, el AS400 no tiene manera, que yo sepa, de "adivinar" la relaciones entre ellos.
Si los sistemas han sido comprados a un proveedor, el proveedor debe darte las relaciones de los archivos de la base de datos.
Este tema es dominado con mayor profundidad, por gente que se dedica a Administrar la Base de Datos en el AS400.
Pueden haber proveedores que te vendan herramientas programadas por ellos para que puedas ver las relaciones entre las tablas, sin embargo estas herramientas deben ser alimentadas manualmente, al crear los archivos, bien sea con meta lenguajes o al momento de crear la Base de datos para que el AS400 pueda almacenar las relaciones de los modelos entidad-relacion de la base de datos y luego tu puedas tener una "vista" de las relaciones entre archivos.
Por ejemplo, en este link: http://aquafold.com/es/index-db2-iseries.html puedes ver un proveedor que hizo una herramienta para visualizar base de datos en el as400, pero como siempre, basada en que los archivos fueron construidos con DB2.
Hasta ahora no conozco otra manera de obtener la información que estas solicitando. Si me llega alguna otra información sobre este tema te la hago llegar.
Si alguno de los lectores del blog, conoce alguna información adicional o específica que pueda proveer de mayor beneficio al tema que estamos publicando nos la puede hacer llegar bien sea a través de comentarios a este articulo o al correo: rpg.iseries@gmail.com luego, publicaremos el autor de la nota y el contenido de la misma.
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
Subscribe to:
Posts (Atom)