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.

Monday, January 25, 2010

Funcionalidades poco conocidas del "Debugger"














Escrito por Generico de WMInformática


martes, 30 de octubre de 2007

En este artículo, les mostramos algunas funcionalidades del "debugger" interactivo de ILE (STRDBG) que son muy útiles cuando estamos en nuestras faenas de encontrar un error.

%SUBSTR Built-In Function

Esta función es muy interesante, sobretodo si usted está trabajando con cadenas de caracteres muy largas.

- Se puede visualizar un segmento de una cadena como se muestra a continuación (suponiendo que StringFldA = 'abcdefghijklmnopqrstuvwxyz'):

Comando : EVAL %SUBSTR(StringFldA 12 5)


Resultado: %SUBSTR(StringFldA 12 5) = 'lmnop'

- Se puede usar la función %SUBSTR para fijar el valor de una parte específica de una cadena. Para mí, esta es la más útil de estas dos funciones.

Comando : EVAL %SUBSTR(StringFldA 12 5) = 'xxxxx'


Resultado: %SUBSTR(StringFldA 12 5) = 'xxxxx'

Comando : EVAL StringFldA


Resultado: StringFldA = 'abcdefghijkxxxxxqrstuvwxyz'

- También puede usar %SUBSTR para establecer un punto de parada condicional o una condición de inspección ("watch").

Por ejemplo, el siguiente código detendrá la ejecución sólo cuando las posiciones 12 a 16 de StringFldA sean "xxxxx":

Comando: BREAK 100 when %SUBSTR(StringFldA 12 5) = 'xxxxx'

- O usted puede buscar por cambio en las mismas posiciones mediante el uso de esta condición de inspección:

<!--[if !supportLineBreakNewLine]-->

<!--[endif]-->

Comando: WATCH %SUBSTR(StringFldA 12 5)

De este modo, en cualquier momento que el contenido de las posiciones 12 a 16 cambie, la ejecución del programa se detiene y se le informa.

%INDEX Built-In Function

La función %INDEX es muy práctica cuando se está utilizando estructuras de datos de múltiples ocurrencias.

También es útil en combinación con _QRNU_DSI_xxxx (donde xxxx = el nombre de una estructura de datos de múltiples ocurrencias).

- El comando EVAL _QRNU_DSI_xxxx devuelve el número de la actual ocurrencia de estructura de datos de múltiples ocurrencias.

- El uso de la función %INDEX cambiará la ocurrencia actual.

Tomemos el siguiente ejemplo:

d WorkDS1 ds occurs(3)
d StringA 10a
d StringB 25a

Comando: EVAL _QRNU_DSI_WorkDS1


Resultado: 1 (o cual sea la actual ocurrencia de WorkDS1)

Comando : WorkDS1 = %INDEX(3)


Resultado: WorkDS1 = %INDEX(3) = 3

(Los subcampos de WorkDS1 visualizados serán los de la tercera ocurrencia.)

Modificado el ( martes, 13 de noviembre de 2007 )


Publicado por: Ing. Liliana Suárez

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

Monday, January 11, 2010

Base de Datos vs. DFU
















Cuando estamos realizando pruebas de programas, generalmente recurrimos al uso del DFU para proveernos de un conjunto de datos improvisados por nosotros mismos para realizar pruebas parciales y unitarias de programas. En general, existe la sensación de que en un ambiente de desarrollo, todo es válido. Puede corromperse la data para realizar pruebas, tener redundancia de información y alterar la data como la requerimos.

En ambientes de desarrollo donde no hay control de versiones, esto puede representar un problema cuando otros programadores necesitan realizar pruebas con los mismos archivos y se encuentran con una data corrompida. Aunque dupliquemos los archivos en nuestras librerías de trabajo personales para manejar la data a nuestro antojo, no debemos olvidar que la situación que estamos forzando “No se ajusta a la realidad”. Ese escenario que estamos produciendo de manera forzosa, probablemente nunca ocurrirá en el ambiente de producción. Entonces ¿Qué estamos probando?.

La elaboración de escenarios de pruebas debe estar basada en un principio de “correspondencia con la realidad” que se presenta en la operativa diaria del negocio.

Las datas de prueban deben ser generadas por las aplicaciones que fueron desarrolladas para tal fin. Las aplicaciones velan para que las validaciones se encarguen de la integridad y la consistencia de la data. Cuando realizamos pruebas en base a data generadas por las aplicaciones, garantizamos que el ambiente de desarrollo sea idéntico a lo que ocurre en el ambiente de producción, que en resumidas cuentas, es lo que sucede día a día en las actividades diarias del negocio.

Es recomendable que los profesionales asignados al mantenimiento y la custodia de los datos sean quienes suministren la data de prueba a los analistas y programadores. Corresponde al personal de Base de Datos colocar en el ambiente de desarrollo una data que simule la data de producción.

En algunas empresas, por razones de estrategia de negocios y protección de la identidad de los clientes, la data debe ser tratada previamente por estos profesionales de Base de Datos antes de ser entregada al ambiente de desarrollo donde todos los analistas y programadores puedan accederla.


Autor: Ing. Liliana Suárez


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

Wednesday, January 6, 2010

Mas sobre Migración
















Cuando se realizan un cambio de plataforma es necesario establecer acuerdos entre dos metodologías de de trabajo que deben coordinarse y sumar esfuerzos para lograr un resultado exitoso.

La migración de sistemas distintos sobre el mismo lenguaje RPG, en plataforma As/400 no es tan traumática como la migración entre un sistema desarrollado en RPG en el AS/400 y un sistema desarrollado en un lenguaje orientado a objetos.

El control del proyecto de migración debe generar una serie de pautas que establezcan puntos de control que sean fácilmente cuantificables por los analistas de ambas plataformas: la plataforma receptora de la data y la emisora donde residen actualmente los datos de origen.

La cultura tradicional del AS/400 ha carecido de cierta solidez en relación a la definición de la Base de Datos, en las pruebas de procesos y en la estandarización del código en el desarrollo del software. Por otra parte, en la programación orientada a objetos el enfoque es funcional y el desarrollo de código es mucho menor. Hay muchas más herramientas y normas de documentación que en la cultura clásica del AS/400.

Para subsanar las diferencias que se suscitan en la forma de controlar el avance del proyecto debe intervenir un tercero en la mesa de discusión. En realidad este tercero en la mesa debe intervenir siempre pero en el cambio de plataformas tecnológicas su participación se hace imprescindible para el éxito de la migración.

La participación de los profesionales del área de Procesos, Organización y Métodos es esencial para levantar la información relacionada con las reglas del negocio, el impacto de los cambios a realizarse y los puntos de control operativo por área de negocio que puedan y deban ser sometidos a certificación antes de la implantación del nuevo sistema.

Una vez recopilada la información sobre la funcionalidad del negocio, establecidos los puntos de control y las funciones operativas que deben certificarse, procede la fijación de un cronograma de actividades que los involucrados del área de sistemas deben cumplir. En este punto entonces los profesionales de ambas plataformas deben establecer compromisos de acuerdo a su “cultura” profesional pero siempre sobre los cimientos construidos por el área de Procesos y Organización y Métodos.

Una definición clara de la funcionalidad del negocio minimiza el impacto que pueda producirse por la salida inesperada de algún analista y facilita la curva de aprendizaje de un nuevo analista que está asumiendo la responsabilidad.

Una gran ventaja de la participación de los profesionales de Procesos, Organización y métodos es que los procesos del negocio quedan documentados. Esto facilita a mediano y largo plazo la adecuación del sistema instalado a los cambios que requiera la organización por cuestiones de estrategia y competitividad de mercado. Con una documentación de los procesos del negocio, puede estimarse con mayor rapidez la factibilidad del cambio, el impacto y el riesgo operativo que representaría para el negocio.


Autor: Ing. Liliana Suárez


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