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, 16 de diciembre de 2014

Control de Procesos
















Hola!  Bienvenidos una vez más a Iseries Venezuela

El Control de procesos es una preocupación constante para gerentes y líderes de proyectos que deben dar la cara cuando un proceso a su cargo falla generando, en algunas ocasiones, consecuencias fatales o el disgusto de un cliente que reclama un mejor servicio.

El tema más delicado y menos tomado en cuenta,  en mi opinión, en el tema de control de procesos es el REPROCESO.

Cuando un proceso que tiene una secuencia de 20 pasos presenta una falla en el paso 13 quedan dos opciones:

1.-Recuperar todos los backups que se tienen “antes de ejecutar el proceso” y ejecutar todo el proceso desde el principio.

2.-Continuar desde donde el proceso falló hacia adelante.
La mayoría de las instalaciones que tienen desarrollos realizados desde los años 80 y 90 optan por la primera solución.

La segunda opción requiere una planificación previa de las fallas en cada paso del proceso para garantizar un reprocesamiento seguro.

Como desarrolladores nos enorgullecemos del conocimiento de muchas técnicas de programación y nos enfocamos en nuestro pequeño mundo llamado “programa”. Cuando integramos nuestro desarrollo a módulos, subsistemas o sistemas conformados por más programas y desarrollos nuestros y de otros programadores,  no planificamos las consecuencias de una falla en cada paso del proceso y tampoco analizamos la manera más eficiente y rápida de solucionar el problema de manera confiable y oportuna. Entregamos nuestro programa y con eso ya “cumplimos”.

En este artículo nos enfocamos en uno de los primeros controles de procesos sencillo que surgió al inicio del surgimiento del as400. 

El uso de área de datos para control de procesos fue una de las primeras ideas que surgió para el control del proceso en as400.  Vamos a partir de que se utiliza un programa CLP principal que ejecuta secuencialmente cada paso.

Cada paso puede realizar cualquier comando como CALL PGM, CRTPF, ADDLIBLE, SBMJOB, etc.

Dependiendo de la actualización de la data y de la naturaleza de los comandos podemos considerarlos pasos individuales o parte de un PASO que agrupa varias acciones. Eso depende del análisis que realice el equipo de trabajo.
Por ejemplo, tenemos un proceso de cinco pasos y declaramos cinco dtaaras y tenemos el siguiente CLP.

PGM

Paso1:
   If cond(dtaara1 = 0) then (do)
     “Ejecutar instrucciones”
    Chgdtaara(dtaara1) value(1)
enddo
Paso5:
   If cond(dtaara5 = 0) then (do)
    “Ejecutar instrucciones”
      Chgdtaara(dtaara5) value(1)
Enddo
 ENDPGM


Aquellos pasos que se ejecutaron sin problemas cambiaran su dtaara al valor 1.

Si el proceso falla en algún punto, el analista puede revisar el status de las dtaaras y realizar los arreglos, respaldo o acciones que se requieran. Luego se puede ejecutar el proceso otra vez sin repetir los pasos previos que no fallaron. La pregunta If Cond(dtaara = 0) evita reprocesar aquellos pasos donde el proceso si pudo culminar.

En artículos posteriores veremos otros mecanismos de control de procesos más elaborados.

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. 

Autor: Ing. Liliana Suárez


sábado, 6 de diciembre de 2014

Recuperando Los Mensajes de Error: RCVMSG














Hola!  A mis seguidores de IseriesVenezuela.

 Gracias por continuar visitando este blog escrito ustedes.

En esta oportunidad vamos a tratar algo sencillo el comando: RCVMSG
Como hemos visto en artículos anteriores, para controlar los errores de ejecución utilizamos frecuentemente el MONMSG en los programas CLP. Sin embargo, aunque este comando evita que el proceso se detenga no nos suministra el mensaje de error que fue monitoreado.

En muchas instalaciones donde se ejecutan procesos nocturnos múltiples y concurrentes resulta una verdadera pesadilla revisar inmensos listados o anotaciones del Log que arroja el sistema operativo durante la ejecución de los procesos.  En esos logs se anota los CALL, CRTPF, ENDJOB e infinidad de operaciones que retornan complicado el proceso de buscar cual fue el resultado del proceso.

El comando MONMSG contempla la ejecución de acciones específicas
 DO(EXEC)… ENDDO
Podemos ejecutar el comando RCVMSG dentro del grupo de instrucciones EXEC del comando MONMSG. En su expresión más sencilla el comando RCVMSG permite recuperar, a través de variables declaradas dentro del programa CLP el mensaje CPFXXXX y su descripción.
RCVMSG   MSGID(&MID) MSG(&MTEXT)
Luego de capturado el id del Mensaje MID y el texto del mensaje, Mtext, podemos grabarlo en un archivo de errores construido por nosotros. 

Una vez terminado el proceso, consultamos nuestro archivo y podemos rápidamente ver que errores fueron monitoreados durante la ejecución del proceso. Construimos el archivo de errores a nuestra conveniencia. Podemos colocar campos como: Proceso, Sistema, Modulo, Fecha, Usuario, Job, Programa que se estaba ejecutando, Hora, Msgid y Msg-texto.

Cada vez que se ejecuta el proceso se puede realizar un CLRPFM del archivo al principio de la ejecución del mismo y con esto evitamos ocupar memoria con mensajes de fechas anteriores. 

Otro uso práctico del archivo sería generar una estadística por día de la semana, usuario, o cualquier combinación de estos campos para determinar si los errores siguen ocurriendo o se han solucionado completamente.

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. 


Autor: Ing. Liliana Suárez

jueves, 30 de octubre de 2014

¿Qué Sabes Sobre Monitor Message MONMSG?

Capturando los mensajes de Error














El comando MONMSG nos ofrece la posibilidad de monitorear los mensajes de error que emite el sistema operativo ante un error de ejecución del programa CLP.

En caso de error, el  programador es quien debe decidir e indicar al sistema operativo la acción a seguir. Si el programador no monitorea el mensaje de error e indica que instrucciones deben ejecutarse en caso de falla, el programa detiene su ejecución.
He visto varios códigos de programas en CLP que colocan el MONMSG antes y después de la instrucción a monitorear ante la incertidumbre de no saber realmente donde debe colocarse.

El MONMSG debe colocarse  en dos eventos estratégicos dentro de un CLP

1.- Al principio del programa.

El objetivo fundamental de colocar el  Monmsg al principio del programa es la de capturar cualquier error imprevisto en la ejecución de todo el programa. 

 -Aquello que se me haya olvidado monitorear en las siguientes instrucciones debe caer en esta “RED” que atrape el error no previsto por mí.-

Para ello utilizamos en general, los mensajes de error CPF0000 y MCH0000
Cabe destacar en este punto que la mayoría de los programadores coloca los mensajes CPF0000 y CPF9999 de manera automática. Parecieran interpretar que con colocar desde el 00000 hasta el 9999 abarca todo el rango de mensajes de tipo CPFXXXX.

Cuando queremos monitorear todos los mensajes de error de una categoría de mensajes es suficiente con colocar las tres primeras letras que identifican la categoría seguidas de ceros. Esto permite capturar todos los mensajes de error de esa categoría. En este ejemplo es suficiente con colocar CPF0000 y no es necesario colocar el mensaje CPF9999 en el monmsg ya que el CPF9999 esta siendo incluido al colocar el mensaje CPF0000.

Lo mismo sucede con MCH0000. Se monitorean automáticamente todos los mensajes de error MCHXXXX.
También podemos monitorear un subconjunto de mensajes en forma global. Por ejemplo, si queremos monitorear los mensajes que comienzan por CPF98XX con rellenar con ceros las 'X' se incluyen todos los mensajes de esa clclasificación. Con colocar: CPF9800 en el MONMSG, es suficiente. 

Con el comando WRKMSGF *all se puede obtener la lista de archivos de mensajes creados en el equipo. Lo archivos de mensajes donde residen los mensajes que genera el sistema operativo comienzan con la letra “Q”. Cada uno de estos archivos de mensajes representa una categoría de errores a monitorear.
El comando WRKMSGF permite ver, a través de varias opciones, la descripción detallada de los mensajes que están registrados en cada archivo de mensajes manejado por el sistema operativo.

Cuando colocamos un MONMSG como primer comando de un programa  CLP es conveniente incluir un EXEC que realiza un GOTO a una etiqueta en la cual se ejecutarán las instrucciones que el programador indique en caso de error.

 Si monitoreamos el error pero no indicamos ninguna acción a seguir, podemos deducir erróneamente que el programa se ejecutó correctamente. La verdad es que nuestro propio monitoreo puede ser “cuchillo para nuestra garganta” porque no fuimos avisados a tiempo de una interrupción inesperada que impidió la conclusión del programa.

En la etiqueta referida en el GOTO podemos colocar un SNDMSG a nuestra cola de usuarios, a la consola, a la cola de mensajes del operador o llamar a un programa que grabe un archivo de errores dando aviso por fecha, hora, proceso y usuario de la caída del programa, por ejemplo. Lo importante es: ¡hacer algo por favor¡


Ejemplo de programa CLP

sábado, 4 de octubre de 2014

SETON LR Versus RETURN
















Bienvenidos a  Iseries Venezuela!        

En esta oportunidad tratamos la diferencia entre SETON LR y RETURN

He observado varios programas que para "finalizar" utilizan SETON LR otros utilizan RETURN y otros utilizan ambos colocando uno y luego otro. Una manera de asegurarse de que el programa en realidad terminó y no se quedó activo como pasa con Terminator II.

Coloco entrecomillado finalizar porque muchos podrán comprobar que si colocan una instrucción luego del seton lr el programa continúa.

El SETON LR tiene la función de cerrar los archivos abiertos, liberar los espacios de memoria y limpiar la pila de programas eliminado de ella, al programa actual activo de la misma y las variables de trabajo que se almacenan en ella. Un seton LR es interpretado de la siguiente manera por el sistema operativo: "Continúa ejecutando la hoja C hasta el final y luego abandona el programa".

En la siguiente secuencia de instrucciones:

                                        Var1 = 1
                                        Seton LR
                                        VAr1 = VAr1 + 1
                                         Write REC
                                         Return

El programa no se detiene en el SETON LR, porque todavía la hoja C, tiene instrucciones pendientes de ejecución por tanto, el programa suma 1 a la variable Var1 y luego graba en el archivo. Finalmente ejecuta el RETURN y en ese momento sí finaliza el programa.

El resultado final es el siguiente

  • Var1 queda con el valor 2 y
  •  En el archivo se graba un nuevo registro.
Si cambiamos el orden de las instrucciones como en este ejemplo:


                                        Var1 = 1
                                        RETURN
                                        VAr1 = VAr1 + 1
                                         Write REC
                                        Seton LR

El programa se detiene al ejecutar el RETURN y no ejecuta el resto de las instrucciones.
Es decir, no incrementa la variable Var1 y no graba un nuevo registro en el archivo.

El resultado final es el siguiente:

  • Var1 queda con valor 1
  • El programa se detiene inmediatamente.
Hasta ahora podemos concluir lo siguiente.

1.-Esta secuencia de instrucciones:
                                         RETURN
                                          SETON LR
NO tiene sentido porque  el seton LR nunca se va a ejecutar.

2.-El Return suspende inmediatamente la ejecución del programa; el seton LR no lo suspende necesariamente

3.-La mayoría de nosotros colocamos seton lr como ultima instrucción de la hoja C puesto que después de ejecutar el SETON LR, no colocamos mas instrucciones después, no queda otra opción para el sistema operativo que finalizar el programa. Por esta razón es que funciona la intención del programador de finalizar el programa. Si colocásemos otras instrucciones luego del SETON LR, muchos verían con asombro que el programa continúa.

Llamada entre programas.

Hice mención anteriormente que el SETON LR limpia la pila de ejecución. En cambio, el RETURN conserva el valor de las variables en memoria y la pila de programas.
¿Qué significa esto? vamos a verlo con un ejemplo.

martes, 9 de septiembre de 2014

Variables y Campos tipo Fecha-(DATE). Segunda parte.

                                                                                                    
 
Hola a los lectores del Blog,!
Gracias por estar siempre presente.

Retomamos el tema de las fechas en este artículo

He desarrollo una pequeña aplicación a manera  de ejemplo para el tratamiento de campos tipo DATE.

El aplicativo consta de un archivo físico, un archivo de pantalla y un programa corto en RPGLE

El objetivo de la aplicación es grabar o buscar los periodos de tiempo y sus fechas de inicio y de finalización. El archivo consta de  una clave que es un numérico de tres y  dos campos: la fecha de inicio del periodo o fecha DESDE y la fecha de finalización del periodo o Fecha HASTA.

Podemos tener por ejemplo una tabla de periodos como sigue:

Periodo            Fecha desde           Fecha hasta
001                   01.0.2014              01.15.2014
002                   16.01.2014            31.01.2014

Etc.

La pantalla permite grabar un nuevo periodo o buscar un periodo que ya existe para que nos muestre las fechas de inicio o finalización que fueron grabadas.
Pueden ver el campo periodo y luego las fechas desde  y hasta.





Si colocamos un periodo, por ejemplo, 001 y presionamos el botón BUSCAR, el aplicativo busca en el archivo el periodo 001 y si lo consigue despliega las dos fechas correspondientes Si no lo consigue emite un mensaje de “periodo no encontrado”.

Cabe destacar lo siguiente:

1.-Los campos de fecha desplegados en pantalla son alfabéticos de 10 posiciones.

2.-Los campos del archivo fueron declarados tipo fecha. (Se coloca una L en la columna correspondiente).

3.- El formato de fecha indicado por mì,  en las DDS y en las variables del programa es *EUR.
En lo personal para mí es más cómodo y coincide  bastante con el formato iberoamericano DDMMAAA. El separador es  PUNTO (.) siendo está una diferencia de forma y no de fondo.

4.-Para desplegar los campos del archivo en pantalla se utiliza la función %char:
Variable de pantalla  = %char(fecha_archivo:*EUR)

5.-Para grabar los campos de la pantalla al archivo se utiliza la función  %date:
Campo del archivo = %date(fecha_pantalla : *EUR)

6.-Las validaciones del aplicativo son básicas. No valida duplicidad ni periodos con fechas limites iguales. Es decir, es algo meramente ilustrativo del manejo de fechas. Cada programador puede realizar los cambios o extensiones que requiera.

En este enlace puedes descargar la aplicación anteriormente descrita
Encontrarás tres documentos en .txt. 

  • La DDS del archivo físico ARCDATE
  • El archivo de Pantalla: SCREENDATE
  • El programa: RPGLEDATE





Hay un montón de funciones que permiten convertir enteros, caracteres en fecha y viceversa. Esto es particularmente útil cuando se desea enviar ráfagas de datos desde el iseries a plataformas distintas al iseries que pueden requerir conversiones especiales de data para ser leídas por los otros equipos.

  
En este enlace tienen varios ejemplos de conversión entre distintos tipos de datos y variables o campos tipo fecha.




 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. 

Autor: Ing. Liliana Suárez







miércoles, 30 de julio de 2014

Variables y Campos tipo *DATE Primera parte.

                                                                              

 












La mayoría de los desarrolladores “clásicos” en RPG prefieren continuar trabajando con campos numéricos de 8 posiciones declaradas en las DDS para almacenar fechas  en los archivos. Esta misma tendencia de las fechas numéricas de 8 posiciones también se aplica en el código de programación. Esta práctica común ha provocado inconsistencia de data en algunas instalaciones.

En algunas instalaciones, cuando revisamos la data que es almacenada bien sea por procesos interactivos, procesos batch o por procesos de recepción remota de data, ha sucedido que algunas fechas se han grabado con el formato ddmmaaaa (diamesaño) otras con el formato mmddaaaa y otras ddmmaa. Esta inconsistencia sucede con frecuencia en envío remoto de data con organizaciones o clientes del negocio que tienen otras plataformas distintas a Iseries/Rpg. (Oracle, Sap, etc)

Con un campo numérico de 8 posiciones, el sistema operativo no puede validar en forma automática si se está cometiendo una trasgresión en contra de la consistencia de la data. Para el sistema operativo se trata de un campo numérico de 8 posiciones que puede contener cualquier dato numérico válido. La interpretación de su contenido, por supuesto, depende del usuario/programador.

Con tantas fechas y tipos de fecha puede parecer complicado lidiar con estos detalles, por lo que en los primeros intentos para trabajar con campos y variables tipo fecha se produce una gran resistencia al cambio.

La clave está en adoptar un estándar de uso para la organización. Luego de que se produzca un consenso con la gerencia de desarrollo y con la fábrica de software de la institución, es sencillo generar plantillas para que los programadores las apliquen a sus desarrollos.

Cabe destacar, que todo este proceso de estandarización está dirigido a asegurar la consistencia de la data de la empresa y del óptimo funcionamiento de la operatividad del negocio que, en primera y última instancia, es lo que se persigue.

Aquellas organizaciones que requieren aplicar formulas en las cuales los días de vencimientos de pago, cálculos de intereses sobre prestamos, intereses de mora y otros conceptos financieros, son la base fundamental para la rentabilidad del negocio están obligadas a asegurar la exactitud del manejo de los campos de fecha en las bases de datos. Esto evita demandas, reclamos, denuncias y pérdidas potenciales de clientes.


Algunas de las razones que han llevado a repetir esta práctica y a no querer incursionar en los campos tipo Fecha son:

  •       ¿Cómo evitar los errores de fuera de rango que producen  fallas   estrepitosas en los programas?

  •      ¿Cómo saber cual fecha está utilizando un job?

  •       ¿Cómo mostrar en pantalla estas fechas?

  •       ¿Cómo enviar data remota a otras organizaciones o a otras plataformas  que no trabajan con este tipo de campos de fecha?


En este artículo voy a responder a dos de estas inquietudes para trata de perder el miedo a utilizar este tipo de datos. (En el siguiente artículo seguiremos con las siguientes dos preguntas)

El primer paso es entender cuantos tipos de fecha hay y cuales son sus rangos.
Esto contestaría la primera pregunta planteada.

En esta tabla puede verse los tipos de campos de fecha agrupados por sus rangos permitidos.




En un vistazo podemos captar el número de dígitos que tiene el año en cada formato y cual es el valor mínimo y el valor máximo permitido para cada uno de ellos.
Esto nos indica que NO podemos inicializar campos de fecha con el valor CERO como hacemos con las variables numéricas. Una de las “caídas” más comunes de los programas se produce por tratar de inicializar fechas en cero. (0).

En la siguientes tablas vemos los formatos y ejemplos que aplican a cada tipo de fecha.














Para determinar con cual fecha trabaja un job es necesario conocer  la jerarquía de prioridades con la que trabaja el sistema.

  1. Primero se verifica las declaraciones de los campos en las dds y en la hoja de declaración de variables del programa (Hoja D en rpg 4 y en rpg free; Hoja E en las versiones anteriores). Los campos y variables serán interpretados en su formato según esta declaración.

  1. Luego se verifica la hoja H donde se especifica el DATFMT. Las variables de fecha cuyo formato no esté especificado en la declaración del programa o en la dds si se trata de un campo, se regirán por el formato especificado en la hoja H

  1. Si la variable o campo tipo fecha no tiene formato especificado en su declaración y tampoco hay un formato declarado en la hoja H, se toma por omisión el formato *ISO para manipular las fechas.

  1. El Job tiene su propia definición de fechas. Cuando hacemos un submit job (SBMJOB) o cuando estamos ejecutando un proceso por interactivo. Las variables del sistema para ese job tienen su formato de fecha. Por ejemplo: Fecha de ejecución del job, (job Date).  Esto significa que si por ejemplo, hacemos en un programa CLP un RTVJOBA (Retrieve Job Atributte) y queremos saber la hora del job se nos devolverá la fecha con el formato que fue especificado en el submit job o con el formato que fue especificado  la jobd description asociada a ese job.

        Continuará...

 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. 

Autor: Ing. Liliana Suárez
















domingo, 29 de junio de 2014

¡Hey!... ¡Eso No Fue lo Que Yo te Pedí!

























Relativamente hace poco tiempo se ha desarrollado una disciplina denominada: Ingeniería de Requerimientos que procura brindarnos una metodología para que podamos definir con claridad lo que el usuario nos pide como desarrolladores de software. Esta disciplina tiene una serie de pasos que pueden variar dependiendo de las estrategias de desarrollo de software que se hayan adoptado. Existe una gran literatura en la web bien extensa y completa sobre este tema. Por tanto, en este artículo me dedicaré a exponer en forma sencilla las prácticas  que me han resultado exitosas en la definición de requerimientos basándome en mi propia experiencia y sin atarme a ninguna tendencia específica aunque pueda estar tomando algunos puntos importantes de ellas.


En mi experiencia, hay dos estrategias fundamentales que garantizan la definición exitosa de un requerimiento:

1.-Divide y Reinaras

Esto significa no esperar hasta el final para hacer entregas ni para realizar verificaciones de las mismas. Esto implica dividir la definición de requerimiento en “fases”.

Cada fase debe de la definición del requerimiento debe:

Ø      Tener al menos un entregable.
Un entregable es algo material, visible y tangible que se presenta al usuario y al equipo de trabajo de las áreas involucradas que constituye una evidencia del avance del ANÁLISIS del requerimiento.
Un entregable puede ser un documento en Word o pdf , una presentación en power point; una exposición donde se muestre cómo sería la secuencia de pantallas y los campos, registros, ventanas y subfiles que habría en cada una de ellas, un archivo grabado en cinta, un video, etc

En lo personal, la secuencia de pantallas es mi favorito.

El entregable hace posible que las objeciones a la definición del requerimiento sean detectadas a tiempo; permite rectificar y unificar criterios;  detectar condiciones de ejecución, de validación o de operatividad que en la solicitud inicial no fueron detectadas.



        
Ø      Propuestas con soluciones verificables.
La verificabilidad es una lista de condiciones que toda propuesta de solución debe cumplir.
    La Lista es la Siguiente:

viernes, 23 de mayo de 2014

Cinco Recomendaciones Para Crear Archivos con DDS


 En esta oportunidad voy a referirme a la clásica creación de “base de datos” utilizando DDS. 

Coloco entre comillas base de datos porque en realidad DDS es un manejador de archivos y no un manejador de base de datos.



Crear Bases de datos con  DB2 tiene una serie de validaciones automáticas suministradas por el DB2 que impiden de alguna manera la generación de algunos “Frankenstein”; en cambio, la libertad del uso de las DDS  si permiten la proliferación de algunas creaturas terroríficas que deambulan en los pantanos de los sistemas de las organizaciones





1.-El Diccionario de Datos.

El uso del diccionario de datos que tuvo su auge en  décadas pasadas ha pasado a ser, en varias instalaciones, una colección mas en el  baúl de los recuerdos. El Diccionario de datos permite mantener la consistencia e integridad de la data. En algunas instalaciones vemos por ejemplo, que unos archivos tienen el código de país de tres posiciones alfabéticos, otros los tienes de dos posiciones numéricos y otros de seis posiciones alineados a la izquierda utilizando solo los primeros dos caracteres. Para evitar esta variedad de definiciones que rompen con la consistencia de la base de datos es importante y fundamental utilizar un diccionario de datos.

2.-Normalización de las Bases de Datos.

Hay material de estudio académicamente certificado que explica como definir una base de datos siguiendo las reglas normalización de primera forma normal hasta quinta forma normal. Es bueno desempolvar lo que aprendimos en las instituciones y llevarlo a las mejores prácticas en nuestros sitios laborales. En los siguientes artículos vamos a ver la aplicación de la normalización de las bases de datos en el desarrollo de programas RPG usando DDS.

3.-NO colocar índices en los archivos físicos.

Colocar claves en los archivos físicos retarda los procesos de recuperación, copia y salvado de la data. Incluso retardan el tiempo de respuesta de los procesos. Es preferible utilizar lógicos, SQL o cualquier otro medio de acceso indexado que satisfaga esa necesidad de ordenamiento.

4.-Deje algunos campos comodín.

Dada la dinámica de los cambios en las normas y reglas del negocio, algunas veces es imposible predecir la necesidad de expandir un archivo creándole mas campos y cuando las modificaciones que requiere el negocio nos lleva a la necesidad de crear campos adicionales preferimos crear otras tablas o archivos que viene a ser la “extensión” del archivo base. Es conveniente crear algunos campos extras de tipo carácter y numérico que permita prevenirnos de modificaciones dramáticas a futuro, que involucre la recompilacion de varios programas que depende de las definiciones de los archivos.
Aunque algunos prefieran crear tablas adicionales, la consulta de estas tablas en procesos nocturnos (hacer chain una y otra vez) puede retrasar el tiempo de respuesta.

5.-Sea consistente en la nomenclatura de los campos.

Aún utilizando el diccionario de datos, los archivos que reposan sobre él en cuanto a su definición pueden tener sus propios nombres de campos según el criterio del analista o las normas de desarrollo del departamento de sistemas.
¿Qué es eso de la consistencia en los nombres?
Por ejemplo para los campos que sean código utilice las tres primeras posiciones de la izquierda como COD  o si lo prefiere CD o de cualquier otra manera. Cualquier sea su elección mantenga esa nomenclatura en todos lados. Si se trata de una descripción y decide utilizar DES utilice DES a lo largo y ancho de la base de datos.
Aunque una longitud de 6 posiciones es bastante corta para describir el concepto del uso de un campo, el respeto por las convenciones de uso y nomenclatura establecidas por el departamento de sistemas y de base de datos, facilita al analista entender rápidamente de qué se trata el contenido de la data.

En el siguiente enlace conseguirás mas información sobre creación de base de datos publicada en otros artículos de este mismo blog.

Haz click aqui:  Bases de Datos


En las próximas entregas voy a ilustrar la definición y el uso paso a paso de una base de datos adaptado a DDS y para desarrolladores RPG además de otras recomendaciones.




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. 



Autor: Ing. Liliana Suárez

sábado, 26 de abril de 2014

Cinco Tips para Reducir el tiempo de Respuesta Mejorando el Código de programación en RPG

 











Optimizar un código de programación persigue dos objetivos:

Ø      Mejorar la legibilidad del código para reducir el tiempo que toma actualizarlo.

Ø      Reducir el tiempo de respuesta de la ejecución del programa

Cinco Tips para Reducir el tiempo de Respuesta Mejorando el Código de programación en RPG


1.-Uso de estructura de datos

En programación RPG II y RPG III, podemos ver, en general, una gran cantidad de MOVE, MOVEL para poder armar claves de búsqueda, grabar información en un archivo, realizar comparaciones de campos de longitud desigual, etc.

Declarar una estructura de datos con los campos o variables  y que tenga definidos los subcampos con sus diversas longitudes, nos permite hacer un solo MOVE y rellenar automáticamente todas las variables auxiliares que hemos utilizado durante el programa y que hemos repetidamente actualizado mediante MOVE y MOVEL.
Esto reduce sensiblemente el tiempo de respuesta del programa

2.-MOVE Versus Z-ADD

Consume menos tiempo de ejecución el MOVE que el Z-ADD
La instrucción Z-ADD implica internamente la realización de dos instrucciones: mover cero a la variable y luego sumarle un valor.
El MOVE directamente coloca el valor.

3.-SELECT Versus If Anidados

Algunas instalaciones tienen una verdadera fascinación por los IF anidados. Parece que mientras mas anidados y mas IF sean más eficiente es el programa: Todo lo contrario.
Utiliza SELECT en lugar de IF Anidados. El Select hace mas legible el programa y al evaluar la condición y verificar que se cumple, el sistema operativo abandona la evaluación del resto de las sentencias y pasa directamente a la siguiente instrucción por lo que el tiempo de respuesta se reduce considerablemente.





4.-Chain de Tablas Pequeñas

A veces tenemos un lazo por ejemplo un DO WHILE que lee un archivo de millones de registros. Por cada iteración se realiza un CHAIN a la tabla de sucursales por ejemplo. Si tenemos 6 millones de registros hacemos 6 millones de chain a una tabla que contiene 50 registros. Este acceso constante al disco para un archivo tan pequeño consume un tiempo enorme de ejecución.
Para reducir el tiempo de respuesta es preferible, al principio del programa, cargar la tabla de sucursales en un par de arreglos. Luego el lazo de los 6 millones de registros hace un Lookup a ese arreglo que fue cargado en memoria y leído solamente 50 veces.
Guao! muy distinto 50 accesos al disco que 5.999.950 ¿verdad?
Notaras la diferencia en tiempo de respuesta inmediatamente de manera impactante.



5.-Condiciones de los Lazos

Podemos realizar lazos de lecturas sobre un archivo DO WHILE  y dentro del lazo evaluar ciertas condiciones para determinar si abandonamos el lazo o permanecemos en el mismo. A veces se cumple la condición para salir del lazo y podemos aplicar un LEAVE en lugar de permanecer leyendo todo el archivo hasta fin de archivo.


Si quieres tener mayor información sobre este tema puedes revisar los artículos publicados por mi anteriormente en estos enlaces:






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. 




Autor: Ing. Liliana Suárez


domingo, 30 de marzo de 2014

Algo más sobre Uso de Indicadores.

 







En un artículo anterior, al comenzar la edición de este blog, hice mención a varias recomendaciones a como usar los indicadores.


En esta oportunidad vamos a mencionar formas arcaicas o en desuso de los indicadores porque me lo han pedido en los últimos comentarios del blog.
Vamos a enfocarnos en:


Como NO utilizar los indicadores.

Hemos visto a programadores de RPG II y RPG III utilizar indicadores de esta forma:

N31N45N78       Move 1  VARIABLE

Algunas variaciones más monstruosas sobre el mismo tema.

N31N45N78    
Or
N78 78N90        Move 1  VARIABLE
     

Lo peor es que cuando incursionan en la programación con RPG IV conservan la misma forma arcaica de programar.

Luego de un tiempo el mismo programador no recuerda que diablos significa N31 N45  N78 y debe comenzar a realizar un análisis “forense” hasta dar con el concepto que involucra cada indicador.

Con RPG IV o con RPG FREE podemos declarar variables tipo Booleana en la hoja ‘D’ .Se declara tipo ‘n’ y listo!.

Por ejemplo si el indicador 31 indica que se aprobó el préstamo del cliente.
¿Por qué no declarar una variable tipo booleana? Una variable llamada: Prestamo_Aprobado.

Podemos hacer: Prestamo_Aprobado = *On  
Podemos hacer: Prestamo_Aprobado = *Off

Y luego preguntar:  If Prestamo_Aprobado 

¿Es más sencillo y claro de entender verdad?

Otro uso arcaico de los indicadores es en las preguntas IF.

If *in03 = ‘1’  no es necesario preguntar si vale ‘1’ con colocar:

If  *in03       Es suficiente.

Lo mismo sucede con el indicador con negación delante:

If  *in03 = ‘0’ se reemplaza por: If Not *in03

Sin embargo la mayoría de los programadores se mantienen con su forma de programar en:
If  *in03 = ‘1’   If  *in03 = ‘0’ formas que denotan falta de claridad del programador en el manejo de las sentencias lógicas.

Es  lo mismo preguntar por *OFF que por ‘0’ al igual que preguntar por *ON que por ‘1’.

Hay instrucciones como el CHAIN el COMP que originalmente utilizan indicadores. Con la nueva programación en RPG-FREE se pueden utilizar operaciones como por ejemplo:

    Chain (Key1:Key2) Archivo    03    (El indicador 03 es opcional)

If %Found(archivo)  equivale a preguntar If  not*in03

La operación COMP que ya NO se usa es reemplazada por una condición estándar de
Comparación:   IF A > B

Otra costumbre en la vieja programación es esta:

45                         A IFGT B
                                 …..
                  ENDIF
Esto significa que si el indicador 45 esta encendido (*ON) ejecutar el IF y todo lo que hay adentro.
Esta es otra práctica que dista de estar entre las mejores prácticas de programación en RPG. Utilice todas las condiciones que necesite en la sentencia IF para despejar cualquier duda de su ejecución.

En Rpg_Free ya no es necesario el uso de indicadores para buscar un elemento en un arreglo (Array)

Posicion= %Lookup(‘hola’: Array: 1:200)

En Posicion  se devuelve la posición del arreglo donde se encontró la palabra ‘HOLA’ si POSICION es cero entonces no está en el arreglo.
Un indicador menos que utilizar y podemos usar una variable mas mnemotécnica (Posicion)


Si puedes utilizar variables estándar o variables booleanas en lugar de indicadores, tendrás suficientes indicadores a tu disposición cuando requieras verdaderamente el uso de indicadores como es el caso del manejo de pantallas. Para ese caso, no hay manera de reemplazar indicadores de pantalla con variables booleanas. El SDA no da espacio para variables booleanas o nombres largos que permitan el manejo de campos y condiciones en Keywords de pantallas para el despliegue y actualización interactiva de datos.

El utilizar RPG-Free nos brinda muchas facilidades que nos permiten ser más claros, sencillos y directos en la programación.

Si quieres “migrar” a RPG-Free revalúa tus técnicas de programación para que no repitas los mismos vicios que aprendiste en códigos de programación mas atrasados.

 Para mayor información sobre este tema puedes consultar este enlace de otro artículo publicado por mí en este mismo blog, hace algún tiempo:



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. 



Autor: Ing. Liliana Suárez