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.

Prueba de Procedures en ILE RPG

Ile Procedures

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.