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, 29 de octubre de 2009

Mejores Prácticas de Programacion RPG












Aunque nos suministren miles de herramientas en el Iseries para desarrollar mejores programas, tendemos a arrastrar viejos hábitos que aprendimos en RPG II y RPG III. Con la incorporación de RPG4 y de Ile-Rpg es fundamental desarrollar códigos "limpios" que a su vez reduzcan tiempos de respuesta en los procesos.

A manera de ejemplo, supongamos que tenemos tres analistas en una competencia. El reto es optimizar el siguiente código en RPG III. Lo dejamos en esta versión de RPG porque muchas veces es utilizado como excusa el hecho de no tener experiencia en RPG4, Free RPG o IleRpg para generar un código engorroso y con un tiempo de ejecución innecesariamente alto.


En un ejercicio de imaginación supongamos los siguientes Costos:
- Cada IF cuesta: un segundo.
- Encender o apagar un indicador: 1 segundo
- Cada Z-add cuesta dos segundos:
son dos instrucciones en una: primero mover cero y luego sumar.
-Cada comparación: 1 segundo
-Llamar a la rutina: 1 segundo

martes, 27 de octubre de 2009

Trabajar con Fechas en RPG










Aunque es muy cómodo permanecer en el campo de lo conocido, es importante en el mundo de la tecnología incorporar herramientas, codigos y mecanismos mas actualizados para desarrollar programas. Todavía se encuentran programas que para validar fechas recurren a aquellos famosos arreglos contenidos al final del programa
donde se definía cual mes del año tiene 28,29 30 o 31 dias. Tambien vemos aquel famoso operador mvr utilizado para saber si un año es o no bisiesto. Con rpg 400 y rpg free, existen nuevas funciones proporcionadas por el sistema operativo que ahorran tiempo de programación y lo mas importante: tiempo de respuesta.
Por ejemplo para saber si una fecha es correcta o incorrecta puedes recurrir a la
función test. Declara previamente la fecha que quieres evaluar y si la fecha es erronea el sistema operativo te devuelve el valor de %error en true (verdadero).
Para evaluar Fecnac. (fecha de nacimiento)

d ds
d Fecnac 1 8 0
d Ano 1 4 0
d Mes 5 6 0
d dia 7 8 0


test(de) *iso Fecnac;
if %error;
enviar mensaje al usuario
endif;
………………………………………………………

En el siguiente ejemplo la función %diff nos da la diferencia de en dias
hemos declarado las fechas julianas pero pueden ser declaradas en formato
*iso u otro que resulte cómodo. En el manual de Rpg Reference pueden ver mas detalles
del formato de fechas

dfecha1 s d datfmt(*jul)
dfeccha2 s d datfmt(*jul)

dias = %diff(fecha1:fecha2:*days);

En la variable dias tenemos la diferencia en dias de ambas fechas,
si queremos la diferencia en meses colocamos en el tercer parámetro
de %diff *months
…………………………………………………

Por último, pero no menos importante, podemos realizar operaciones con fechas con las funciones subdur y adddur.

d fechahoy s d datfmt(*eur)
d fechapago s d datfmt(*eur)
d fechafinal s d datfmt(*eur)
d dias s 5 0

fechahoy subdur 3:*m fechafinal

fechahoy subdur fechapago dias :*d


En la primera instrucción restamos 3 meses a la fecha de hoy y obtenemos una fecha resultante.
En la segunda instrucciñon restamos dos fecha y obtenemos el resultado en terminos de dias.
La función Adddur es similar pero en lugar de restar suma los tiempos o fechas
que le indiquemos.

Estas funciones son muy importantes para el cálculo de fechas de vencimientos de pago, intereses, terminos de contratos, entregas de pedidos y miles de transacciones comerciales que se definen en costo y ganancia por el tiempo transcurrido. Ya no se hace necesario desarrollar un programa o diseñar un procedimiento que se encargue de devolvernos el resultado de la operación que requerimos ejecutar con las fechas.

Continuamente se realizan avances en el RPG es nuestro deber mantenernos actualizados.

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

domingo, 25 de octubre de 2009

No puedo ver el listado del Debug.











Cuando un programa falla y respondemos con ´D´ esperamos que se genere un listado
que nos facilite conseguir el origen del problema. Este listado puede generarse en el spool del usuario o en una cola de spool predeterminada por el sistema llamada QEZDEBUG. Sin embargo, puede suceder que buscamos el listado por todas partes y no lo conseguimos. El nivel de autoridad puede estar implicado en este problema. Para solucionarlo, colocas WRKSPLF y luego presionas SHIFT-F9. Seguidamente te aparece una pantalla que dice: Nivel de Autoridad. Colócalo en 2, pulsas Enter y al presionar F5 para hacer un refrescamiento de la pantalla del WRKSPLF verás el listado que estabas buscando

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

sábado, 17 de octubre de 2009

Frases Célebres

















“La prueba del software puede ser muy efectivo para mostrar la presencia de errores, pero absolutamente inadecuado para demostrar su ausencia”
Edsger Dijkstra

“Cuando se está depurando, el programador novato introduce código correctivo; el experto elimina el código defectuoso”
Richard Pattis

“Unas buenas especificaciones incrementará la productividad del programador mucho más de lo que puede hacerlo cualquier herramienta o técnica”
Milt Bryce

“Programar sin una arquitectura o diseño en mente es como explorar una gruta sólo con una linterna: no sabes dónde estás, dónde has estado ni hacia dónde vas”
Danny Thorpe

“Ley de Alzheimer de la programación: si lees un código que escribiste hace más de dos semanas es como si lo vieras por primera vez”
Via Dan Hurvitz

“Está bien investigar y resolver misteriosos asesinatos, pero no deberías necesitar hacerlo con el código. Simplemente deberías poder leerlo”
Steve McConnell

“En el mundo del software, los activos más importantes de la compañía se van a casa todas las noches. Si no se les trata bien, pueden no volver al día siguiente”
Peter Chang

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.


Publicado por: Ing. Liliana Suárez

jueves, 15 de octubre de 2009

Migración




El proceso de migracion de un sistema a otro o de una plataforma tecnológica hacia otra suele ser traumático.

En general la situación se complica cuando existen dos grupos separados que conocen lo que hay dentro de sus fronteras pero desconocen el territorio desde o hacia el cual hay que convertir la data.

Es importante una estrategia bien definida que sea aplicable a la situación en particular y es neceario no quedarse anclados en formulas pre-establecidas que no encajan con la situación particular que se está enfrentando.

En general hay tres estrategias para migrar datos.

1.-Convertir data comenzando por las tablas básicas del sistema e ir haciendo pruebas paralelas por submódulos y módulos.
Esto requiere, tiempo, recursos de personal adicionales y jornadas laborales extras no solo para el área de Sistemas sino para lo usuarios del la empresa.

2.-Convertir la data comenzando por la contabilidad. Es decir, ir en sentido inverso. Como todos los sistemas terminan en la contabilidad, comenzar realizando paralelos en el area de contabilidad e ir convirtiendo cada modulo progresivamente hasta llegar a las cargas iniciales de datos.

3.-Una combinación de las anteriores.


En particular prefiero comenzar con la segunda estrategia, porque el proceso de generar la contabilidad progresivamente e ir haciendo paralelos en este módulo en particular develará la necesidad de crear tablas intemerdias de conversión que nadie imaginaba que eran necesarias para poder contabilizar con el nuevo sistema.

En esta estrategia, se descubren manejos inesperados de data que no fueron considerados por los analistas en las fase iniciales de la planificación del proceso de migración.

Cada vez que un módulo contabiliza correctamente en el nuevo sistema puede irse "despegando" progresivamente del sistema viejo hasta el proceso final que integra todo el sistema nuevo y sus componentes.

El monitoreo constante de la situación es un mecanismo indispensable para girar la dirección del barco en la vía correcta e ir variando de estrategia en caso de que por alguna eventualidad inesperada sea necesario combinar ambas estrategias o aplicar una por encima de la otra. Lo importante es la flexibilidad y apegarse a la REALIDAD de lo que está sucediendo, dejando a un lado los academicismos rígidos que pueden entorpecer el desarrollo exitoso del proceso.


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