Detección de memory leaks - Parte IV (MTA)

En la entrada anterior (III) vimos como detectar memory leaks utilizando discover en una aplicación que ha sido desarrollada utilizando el framework MTA de BRM. Ahora veremos como hacerlo con otra herramienta: dbx (ésto también sirve para apliaciones que no han sido desarrolladas utilizando MTA, pero el post está orientado a este tipo de aplicaciones).

Reutilizando código, linkeo de librerías

He visto en muchos proyectos que se hace copy/paste de código y se lo va desparramando a lo largo de distintas librerias/apps en vez de tener una función en una sola librería e invocar esa función desde otras librerías/apps en vez de andar copiándola y pegándola por todos lados.

Por ejemplo: una función para obtener el poid de la /account dado el PIN_FLD_ACCOUNT_NO, eso se usa mucho en casi todas las librerías custom del proyecto y por lo general se la ve la misma función en todos los módulos, entonces, por qué tenerla por todos lados y no solo en uno e invocarla desde el resto de las librerías?

Ésto a veces se hace porque los desarrolladores no se ponen de acuerdo al principio para tener una librería con funciones que se utilizarán en casi todos los módulos o porque a veces  no saben como invocar una función que está en otra librería.

IEL: primeros pasos. Parte 1

En este post vamos a ver como dar nuestros primeros pasos con el IEL - BRM Event Loader.

Para configurar el IEL tenemos 2 archivos:

1. iel.cfg:aquí se configura el IEL en sí.
2. pin.conf: aquí se configuran los parametrós de conexión a BRM.

El archivo iel.cfg tiene la siguiente estructura (familiar con la estructura de un XML):

Setear el Developer Center para que reconozca los campos custom

Cuando creamos nuestros propios campos para BRM y luego los utilizamos en el Developer Center en algun opcode o campo de una clase custom vamos en donde iría el nombre del campo custom se ve UnknownFieldXXX, donde XXX es el id del campo. Así se ve en el Developer Center:

Performance: Usando el opcode PCM_OP_STEP_SEARCH

A veces cuando ejecutamos una búsqueda el resultado de la misma es de cientos o miles de registros (por ejemplo llamadas telefónicas) por lo que no es recomendable utilizar el PCM_OP_SEARCH (puede dar error en el dm_oracle por hacer que utilice toda la shared memory, o la performance decaerá) y es conveniente procesar esos registros en bloques mas pequeños, entonces utilizaremos el PCM_OP_STEP_SEARCH.

El uso del PCM_OP_STEP_SEARCH tiene 2 ventajas frente al PCM_OP_SEARCH: