Вы находитесь на странице: 1из 18

OPM Vs ILE

Las versiones de RPG anteriores a RPG IV ILE utilizan lo que IBM ha


denominado Modelo de programa original (OPM). La contraparte de OPM es ILE
(Integrated Language Environment). OPM se caracteriza por la estructura de un
miembro fuente compilado en un programa ejecutable (figura 1).

ILE, por otro lado, requiere un proceso de dos pasos para crear programas. Los
miembros de origen se compilan primero en objetos tipo módulo (tipo *
MOD). Para RPG, se utiliza el comando CRTRPGMOD (crear módulo RPG) o la
opción 15 de PDM. Los módulos pueden considerarse subprogramas. Son
códigos de máquina validados y compilados, pero no son ejecutables. Uno o más
módulos deben vincularse a un programa ejecutable mediante el comando
CRTPGM (crear programa) (figura 2).

Tenga en cuenta que los módulos creados con diferentes lenguajes de


programación pueden estar vinculados al mismo objeto de programa. Esta es la
estructura de los programas ILE.

Esta estructura se aplica, incluso si el comando CRTBNDRPG (crear RPG


enlazado) de un solo paso se usa para compilar el programa. De hecho, puede
pensar en el comando CRTBNDRPG como un "contenedor" alrededor de los
comandos CRTRPGMOD y
+. El módulo se crea en la biblioteca QTEMP y el proceso de dos pasos es
transparente para el usuario (figura 3).

Es importante tener en cuenta esta jerarquía de programas ILE. Digamos, por


ejemplo, que queremos usar el comando WRKPGM (trabajar con programas)
para determinar la fecha de cambio del miembro de origen que se usó para crear
un programa. Si el programa es OPM, simplemente podemos mostrar los
atributos del programa.

Por otro lado, si el programa es ILE, los miembros de origen no están asociados
directamente a un programa. En su lugar, un miembro de origen se utiliza para
crear un módulo, y uno o más módulos se utilizan para crear un
programa. Mostrar los atributos de un programa muestra, entre otras cosas, los
módulos utilizados para crear el programa. Al mostrar los atributos del
módulo (todo esto se puede hacer a través del comando WRKPGM) podemos
determinar la información de la fuente. Tenga en cuenta que debemos pasar por
este paso adicional porque un programa ILE en realidad puede crearse a partir
de varios miembros de origen.

También tenga en cuenta que el comando CRTBNDRPG crea el módulo en la


biblioteca QTEMP. Esto parece implicar que una vez que se crea el programa,
el módulo ya no es necesario. Esto es realmente cierto. El objeto de programa
contiene una copia completa del módulo. La excepción a esto es cuando se
usan programas de servicio. Los programas de servicio son un concepto
ligeramente más avanzado que permite crear un programa con referencias a
módulos en lugar de hacer una copia separada de ellos.

Toda esta información se cubre con mucho más detalle en la sección ILE. Ahora
que tiene una comprensión decente de las diferencias entre OPM. El siguiente
paso es familiarizarse con las diferencias de lenguajes entre RPG III y RPG IV.

Hay muchas diferencias entre las 2 versiones de RPG, en la tabla 1 se describen


algunas de ellas:
Tabla 1.
Características RPG RPGILE
Se ejecuta en el entorno ILE (Integrated Language Environment)  
Se ejecuta en el entorno OPM (Modelo de programa original)  
Admite nombres de campo largos Y prefijos para nombres de
campo.  
Soporta BIFs (Funciones incorporadas)  
Permite el uso de programas y módulos de servicio  
Permite el formato libre de código RPG  
Soporta el uso de otros Lenguajes, como ILE / C / Cobol / Java  
RPG400 se basa en RPG III y RPGLE se basa en RPG IV, que ofrece las funciones
mencionadas anteriormente.

RPG IV e ILE no son exactamente iguales. Puede estar programando en RPG IV


usando todas esas características como Funciones incorporadas, formato libre,
nombres más largos, prefijo para nombres de campo, estructuras de datos
calificados y aún el entorno es OPM no ILE.

ILE Significa llamada estática, los programas obtienen toda la información sobre
el programa llamado en el momento de la compilación. Es el proceso
vinculante. Luego, en el tiempo de ejecución, la llamada es más eficiente que el
antiguo método de llamada dinámica utilizado por OPM. OPM se ejecuta en el
Grupo de activación predeterminado y los programas ILE en uno diferente que
podría ser *NEW, QILE (Grupo de activación genérico para ILE), o cualquiera
que sea el nombre que desee.

Los grupos de activación son sub-entorno dentro de un trabajo.

RPG/400 es un producto maduro. Todos los programas RPG / 400 se


ejecutarán en un 400 actual, se pueden editar y mantener como RPG/400,
editar y compilar. El lenguaje funciona y seguirá funcionando.

El código RPG / 400 se puede convertir en código RPG IV con un solo comando.
Hoy en día, el código RPG IV se puede escribir en dos formatos, formato basado
en columnas fijas que es como RPG/400 y un diseño de formato libre. Desde su
inicio, RPG IV ha tenido la adición de muchas características nuevas. Algunos
códigos RPG/400 no se pueden traducir al formato Libre, pero el código de
formato libre y fijo puede existir en un solo archivo.

Como se describió anteriormente, el RPG IV proporciona capacidades ILE que le


permiten usar llamadas prototipadas, objetos creados a partir de múltiples
módulos y programas de servicio.
Programa de Servicio
Un programa de servicio es un programa que agrupa funciones que vamos a
llamar desde distintos programas de forma dinámica como si fueran una
función del sistema del tipo %CHAR, etc...

Para crear un programa de servicio utilizaremos el mandato CRTSRVPGM, que


a continuación vamos a ver en detalle.

Parámetro SRVPGM, aquí ponemos el nombre de nuestro programa de servicio,


en este caso vamos a llamar PRUEBA.

Parámetro MODULE, aquí el nombre del módulo, o módulos que van a formar
el programa de servicio. En este caso FUNDMYAISO.

Parámetro EXPORT *SRCFILE tal como viene por defecto

Parámetro SRCFILE (BIBLIOTECA/QSRVSRC) siendo biblioteca la biblioteca


donde guardes tus fuentes y QSRVSRC el archivo que el sistema propone para
guardar las fuentes del enlazador. Ambos se pueden cambiar al gusto del
programador.

Parámetro SRCMBR *SRVPGM tal como viene por defecto.

Parámetro TEXT texto para identificar que hace este programa de servicio.

Si ahora pulsamos intro nos dará un error, si indagamos en la causa nos


encontraremos con que el miembro prueba no existe el archivo QSRVSRC.
Esto quiere decir que cuando hemos indicado *SRVPGM en el parámetro
SRCMBR le estábamos indicando que existe un miembro llamado como el
programa, donde hemos guardado la información de enlace para el programa
de servicio. Esto se llama Fuente del enlazador.

Crear un miembro Fuente del Enlazador


Una fuente de enlazador contiene la lista de los procedimientos exportados de
un programa de servicio, cada programa de servicio debe de tener el suyo.
Para este caso nuestro miembro enlazador se llamará PRUEBA y será del tipo
BND.
Son miembros que no se compilan y que se limitan a contener los módulos
exportados de cada programa siguiendo la siguiente estructura

STRPGMEXP PGMLVL(*CURRENT) SIGNATURE('PRUEBA')

EXPORT SYMBOL(FUNDMYAISO)

ENDPGMEXP
Aquí iremos añadiendo líneas EXPORT por cada módulo que añadamos al
programa de servicio, antes lógicamente de hacer el CRTSRVPGM.

Para no tener problemas a la hora de modificar el programa de servicio es


recomendable respetar el orden, si añado un nuevo módulo siempre se debe
hacer por el final.

Creamos el programa de servicio (ahora si)

Ahora si ejecutamos CRTSRVPGM pulsamos F4 y lo cumplimentamos de esta


forma.

Crear Programa de Servicio (CRTSRVPGM)

Teclee elecciones, pulse Intro.

Programa de servicio . . . . . . PRUEBA Nombre


Biblioteca . . . . . . . . . . PRUEBA Nombre, *CURLIB
Módulo . . . . . . . . . . . . . FUNDMYAISO Nombre, genérico*, *SRVPGM...
Biblioteca . . . . . . . . . . PRUEBA Nombre, *LIBL, *CURLIB...
+ para más valores

Exportar . . . . . . . . . . . . *SRCFILE *SRCFILE, *ALL


Exportar archivo fuente . . . . QSRVSRC Nombre, QSRVSRC
Biblioteca . . . . . . . . . . PRUEBA Nombre, *LIBL, *CURLIB
Exportar miembro fuente . . . . *SRVPGM Nombre, *SRVPGM
Texto descriptivo . . . . . . . PRUEBA PGM DE SERVICIO

Pulsamos intro y ahora si nos debe de crear el programa de servicio en la


biblioteca PRUEBA, formado por un solo módulo que se llama FUNDMYAISO.

Con WRKSRVPGM podemos trabajar con todos los programas de servicio.

Olo añadir que al ser un programa de servicio cuando modifiquemos el módulo


FUNDMYAISO, lo compilaremos como módulo y después haremos un
UPDSRVPGM del programa PRUEBA para actualizar el programa de servicio.
Todos los programas que usen ese FUNDMYAISO empezarán a usar la nueva
versión con los cambios.

En la próxima entrada veremos cómo podemos usar un programa de servicio


desde cualquier programa ILE compilado con la opción 14 del PDM es decir con
CRTBNDRPG.
Como Compilar un Programas de Servicio

La compilación de un programa de servicio escrito en lenguaje RPG en un


sistema iSeries consta de los siguientes pasos:

1. Introducir la fuente con el código principal y la fuente


con los prototipos

Vamos a suponer que queremos generar el programa de servicio SRAGM


cuya fuente con el código principal radica en QRPGLESRC, y que en QCOPYSRC
se sitúe la fuente PSRAGM con el código de los prototipos.

2. Compilar el fuente y generar el módulo a enlazar

SBMJOB CMD(CRTRPGMOD MODULE(SRAGM) DBGVIEW(*ALL)) JOB(SRAGM)

Con esta instrucción se somete la compilación del módulo SRAGM, con el


comando CRTRPGMOD, que se emplea con la opción DBGVIEW(*ALL) para que
podamos acceder al fuente si estamos en modalidad de depuración.

El resto de opciones que se especificaban explícitamente para crear un módulo


C se toman aquí por defecto, o se complementan en las hojas H del código
fuente.

3. Crear la lista de enlace y especificar las dependencias


externas del módulo

Hay que utilizar la instrucción CRTBNDDIR SRAGM para crear la lista, y luego
el mandato WRKBNDDIR SRAGM para añadir las dependencias, que en este
ejemplo sería:

Work with Binding Directory Entries

Binding Directory: SRAGM


Type options, press Enter.
1=Add 4=Remove
--------Creation---------
Opt Object Type Library Date Time
SRAGG *SRVPGM *LIBL 02/21/09 11:31:42
SRRCW *SRVPGM *LIBL 03/06/09 14:44:16
4. Crear la lista de exportación

En PSRAGM se expresan los prototipos de las funciones que se van a exportar a


efectos de compilación de otros módulos escritos en RPG, pero a la hora de crear
el programa de servicio hay que crear un fuente que contenga las
especificaciones de exportación que se utilizan para generar su signatura.

En el ejemplo se usa la fuente SSRAGM ubicada en QSRVSRC. Si se examina


puede comprobarse que se emplea una técnica de signatura evolutiva con cierre
fijo a nueves. Esta construcción asume que se dispone de un sistema externo de
examen y control de la evolución de las signaturas; si se carece de el, es
equivalente a eludir la verificación de signatura, aunque con la ayuda de poder
consultar la evolución teórica de signaturas.

5. Compilar el programa de servicio

SBMJOB CMD(CRTSRVPGM SRVPGM(SRAGM) SRCMBR(SSRAGM) TEXT(SRAGM) BNDDIR(SRAGM)


ALWLIBUPD(*YES)) JOB(SRAGM).
Con esta instrucción se somete la compilación del módulo SRAGM, mediante el
comando CRTSRVPGM, que se emplea con las opciones:

CRTSRVPGM SRVPGM(SRAGM) SRCMBR(SSRAGM) TEXT(SRAGM) BNDDIR(SRAGM)


ALWLIBUPD(*YES)

SRCMBR(SSRAGM): Indica que se emplea el fuente SSRAGM con las


especificaciones de exportación del programa
BNDDIR(SRAGM): Indica que se utiliza el directorio de enlace SRAGM que se
creó con el CRTBNDDIR.
ALWLIBUPD(*YES): Indica que se permite actualizar el programa con
UPDSRVPGM sin necesidad de recompilarlo

Tras estos pasos se generaría el programa de servicio SRAGM que puede


consultarse con el mandato DSPSRVPGM para ver la lista de procedimientos
exportados, las signaturas soportadas, etc.

Esta última parte coincide con la entrada dedicada a la generación de


programas de servicio escritos en C, puesto que la arquitectura de enlace los
programas de servicio es independiente del tipo de lenguaje empleado en la
creación de los módulos que le compongan.
ILE. Conceptos
Pero realmente ¿qué es?

Puedes buscar el acrónimo en cualquier libro de Ibm pero creo que eso no es lo
interesante. Desde mi punto de vista, ILE es una estrategia de diseño de
aplicaciones. Para que sea útil debe estar concebido en el momento del diseño.

La estrategia de diseño de aplicaciones con ILE no es nueva. Se basa en algo


tan antiguo como "el divide y vencerás". Las cosas pequeñas son más fáciles de
gestionar y mantener... ¡y reutilizar!

Antiguamente hacíamos programas larguísimos (monolíticos con miles de líneas


de código) donde estaba todo el código de cualquier funcionalidad compleja. Así
el desarrollo era muy complejo pero peor era el mantenimiento ya que añadirle
cualquier nueva funcionalidad era muy pesado en un programa tan grande.

Toda esta problemática la podemos solventar


realizando pequeñas funcionalidades en diferentes objetos y después mezclar
todos estos objetos en un ejecutable. Esto lo permite ILE con sus piezas pero lo
realmente importante es definir la división en pequeñas funcionalidades.

Desarrollar funciones pequeñas es mucho más sencillo que realizar


megaprogramas y cualquier modificación posterior es infinitamente más sencilla.

En este primer artículo trataré los conceptos que dan forma a ILE y en sucesivos
artículos indicaré la estrategia de diseño que he adoptado con el objetivo de
facilitar el desarrollo de aplicaciones y mejorar el mantenimiento de aplicaciones.

¿De que está compuesto?

Se basa en cuatro conceptos:

 El primero no tiene un nombre definido ya que en sí no es un objeto del


sistema operativo. Lo podemos conocer como componente, prototipo (o incluso
método acercándolo a la denominación de otros lenguajes de programación) .
 Módulo (*MODULE)
 Programa de servicio (*SRVPGM)
 Programa (*PGM).

Componente
Un componente serían unas líneas de código (en general relativamente pocas)
que realizan una funcionalidad concreta. Por ejemplo, calcular una determina
tasa asociada a un importe.
Permite recibir un conjunto de parámetros de entrada y permite,
opcionalmente, devolver un conjunto de parámetros de salida.
Ejemplo de código de componente que recibe dos parámetros y devuelve como función un valor.

PCalculaTasa B
DCalculaTasa PI 15 4
D Importe 15 2 Const
D Pais 3 Const

D W_Tasa S 15 2
/Free
//Calcula los impuestos
Select;
When Pais = 'ESP'; // España
W_Tasa = Importe / 12;
Other; // Para cualquier otro pais
W_Tasa = Importe / 10;
EndSl;
Return W_Tasa;
/End-Free
P E

Para completar la definición es necesario lo que se conoce como un prototipo


que simplemente es la definición de la interfaz de llamada para que pueda ser
conocida desde la fuente desde donde se utiliza.

Ejemplo de prototipo

PCalculaTasa B
DCalculaTasa PI 15 4
D Importe 15 2 Const
D Pais 3 Const

Desde la fuente donde se desea utilizar habría que añadir la llamada a la


funcionalidad
Ejemplo de llamada. Llama a la función pasándole el valor del importe y el país
y devolverá el cálculo sobre las variables Tasa1 y Tasa2.

Tasa1 = CalculaTasa(WImporte : 'ESP');


Tasa2 = CalculaTasa(WImporte : 'FRA');
Interno o Externo

Atendiendo a su ámbito, pueden ser internos a una fuente, es decir,


su ámbito de ejecución es solo en la fuente en el que está definido
o externos de forma que pueden ser llamados desde otras fuentes. Por
aproximación, los internos vendrían a sustituir o serían como las rutinas
internas (exsr). En los internos el código del componente y el prototipo están en
la misma fuente que lo utiliza y en los externos, la fuente que lo utiliza SOLO
tiene el prototipo
Para facilitar la modificación e inserción los prototipos se suelen poner en un
fuente /Copy y se inserta en el fuente que lo necesita.

El ejemplo anterior sería interno ya que en la definición del componente no


aparece la clave EXPORT. Así para poder convertirlo en externo habría que poner
dicha clave a nivel de definición.

PCalculaTasa B Export

Función y procedimiento

El componente se puede definir de dos formas; como función cuya diferencia


es que devolverá un determinado valor de un tipo o como procedimiento.

Para definirlo como función es necesario declarar el tipo de valor a devolver


sobre el nombre de la función y además deberá tener al menos una
instrucción return que finalizará la ejecución del componente y devolverá el
valor a quién le llamó.

Ejemplo de definición de función con parámetro de retorno numérico de 15,4

PCalculaTasa B
DCalculaTasa PI 15 4
D Importe 15 2 Const
D Pais 3 Const

D W_Tasa S 15 2
/Free

...

Return W_Tasa;
/End-Free
P E
Ejemplos de uso de la función desde cualquier proceso

Tasa1 = CalculaTasa(WImporte : 'ESP');


If CalculaTasa(WImporte : 'FRA') > 1000;
...

Para definirlo como procedimiento, NO debe tener definición de parámetro a


nivel de nombre de componente y no se puede utilizar la instrucción return. Por
otra parte se pueden definir n parámetros de salida.

Ejemplo del mismo código de componente como procedimiento

PCalculaTasa B
DCalculaTasa PI
D Importe 15 2 Const
D Pais 3 Const
D Tasa 15 2
/Free
//Calcula los impuestos
Select;
When Pais = 'ESP'; // España
Tasa = Importe / 12;
Other; // Para cualquier otro pais
Tasa = Importe / 10;
EndSl;
/End-Free
P E

Ejemplos de uso del procedimiento desde cualquier proceso

CalculaTasa(WImporte : 'ESP' : Tasa1);


CalculaTasa(WImporte : 'FRA' : Tasa2);
If Tasa2 > 1000;
...

Parámetros

La ventaja de los componentes es la facilidad de gestionar los parámetros de entrada y


de salida y la potencia que les aporta ya que incluso permite definir un parámetro
opcional facilitando su llamada desde otros objetos (incluso cuando se modifica)
Los parámetros pueden ser de entrada y salida. Para ello se definen que se "pasen" por
valor o por referencia. Si se pasan por valor (se definen como const) no se podrán
modificar pero si se definen por referencia, se podrán modificar en el código interno del
componente y así se devolverán al que le llamó.

También se pueden definir parámetros como opcionales, es decir, que desde


donde se le llame al componente se informe ese parámetro o no. Una de las
posibilidades es utilizando options(*nopass) como clave. Lo único es que el
componente debe estar preparado en su código para recibir solo parte de los
parámetros y para ello utilizaremos la BIF %Parms que nos indicará el número
de parámetros que se reciben. Internamente SOLO podremos utilizar ese
parámetro si se ha recibido. Si intentamos utilizarlo sin haberlo recibido,
obtendremos un error. Por ello se utiliza %Parms para conocer si lo podremos
utilizar.
Esto es útil cuando se van variando componente a lo largo de la vida pero no se
tienen que "tocar" todas las llamadas que se estuvieran haciendo en otros
procesos.

Siguiendo el ejemplo, supongamos que ahora hay una nueva versión del
componente que permite recibir un descuento para el cálculo de la tasa pero
hay mucho programas que lo utilizan que deberían seguir comportándose igual
y sin cambiarse.

Ejemplo de la nueva versión del componente

PCalculaTasa B

DCalculaTasa PI 15 4

D Importe 15 2 Const

D Pais 3 Const

D Descuento 15 2 Const Options(*Nopass)

D W_Tasa S 15 2

D W_Descuento S 15 2

/Free

If %PARMS>=3;

w_Descuento = Descuento;

Else;

w_Descuento = *Zeros;

EndIf;
//Calcula los impuestos

Select;

When Pais = 'ESP'; // España

W_Tasa = (Importe - w_Descuento) / 12;

Other; // Para cualquier otro pais

W_Tasa = (Importe - w_Descuento) / 10;

EndSl;

Return W_Tasa;

/End-Free

P E

Las llamadas antiguas seguirán funcionando perfectamente sin tener que modificar el código.

Tasa1 = CalculaTasa(WImporte : 'ESP');


If CalculaTasa(WImporte : 'FRA') > 1000;
...

Y se podrán codificar nuevas llamadas con los nuevos parametros

TasaX = CalculaTasa(WImporte : 'ESP' : wDescuento);


...

Módulo
Es un objeto compilado en el sistema operativo (*MODULE). Resulta de la
compilación de un fuente de un lenguaje determinado y preparado para ILE
(Rpg, Cobol, Cl, etc.)
Un módulo en sí mismo NO es ejecutable. Se utiliza para recopilar una o varias
funcionalidades en una fuente. Un módulo puede "llamar" a otro modulo. Utilizo
los módulos para:

Módulo de componentes. Incluir en él varios componentes "relacionados".


Imaginemos un conjunto de rutinas reunidas en un módulo. Por ejemplo, que
tuviera las rutinas del cálculo del Pvp, del cálculo del IVA, del cálculo del
descuento x, etc. Es decir, tendría los fuentes de la n componentes.
Estos componentes serán externos (EXTPGM) para que puedan ser
utilizados desde otras fuentes.

Módulo con componentes

Módulo de pantalla. Hacer la funcionalidad de uso de una pantalla. Por ejemplo,


tengo un módulo para presentar un sub archivo de registros de la lista para un
mantenimiento, tengo otro módulo para realizar el mantenimiento de un
registro, etc.
Es decir, divido las funcionalidades visuales de una aplicación para poner una
ventana en cada módulo.
Desde el punto de vista de desarrollo y mantenimiento es más sencillo (y
reutilizable) hacer un fuente con cada pantalla y que se llamen entre ellos que
hacer un solo fuente con n pantallas (monolítico). Lógicamente tener en un solo
fuente TODOS los procesos y flujos relacionados con varias pantallas es
muchísimo más complicado que tener un fuente en cada modulo por cada
pantalla, más acotado, simple y controlado y sin mezclarse datos ni flujos, ni
variables.
Esto es posible porque llamadas entre módulos se resuelven en tiempo de
compilación por lo que es como si fueran rutinas internas y por lo tanto NO
degrada la ejecución.
Fuente monolítico vs. módulos

Programa de Servicio

Es un objeto en el sistema operativo (*SRVPGM). Resulta de "unión" (link) de


uno o varios módulos y opcionalmente otros programas de servicio.
Los programas de servicio permiten "encapsular" funcionamiento y rutinas que
se utilizarán en varios programas. NO es ejecutable por si mismo.

Después desde un programa se utilizará el programa de servicio llamando a las


rutinas o componentes comunes.
Programa de servicio

En una estrategia correcta en un programa de servicio se deberían incluir


aquellos componentes que puedan ser utilizados en varios programas.
Después se crearan programas ejecutables que utilicen los componentes de ese
programa de servicio.

Las ventajas adicionales que tienen los programas de servicio es que, con cierto
cuidado, se puede modificar el código e incluso incluir nuevos componentes ¡sin
tener que compilar los programas donde ya se está utilizando!
Los programas de servicio tienen una especie de lvlchk
denominado signature que identifica una determinadas características que tenía
el programa de servicio cuando se creó. Además, un programa de servicio puede
(a través de un lenguaje especial Binder) almacenar todas las signatures de las
diferentes características por las que ha ido cambiando el programa de servicio.
Cuando se ejecuta un programa que tiene asociado un programa de servicio, lo
primero que se revisa es que la signature que tiene almacenada el programa con
referencia al programa de servicio está entre las signature que tiene el programa
se servicio. En caso contrario, dará error y no se ejecutará el programa. Lo que
significa esto es que la revisión de los componentes incluidos en un programa
se servicio que son utilizados por un programa se realiza en tiempo de
ejecución.

Cuando un programa utiliza un programa de servicio, en tiempo de ejecución,


se carga el programa de servicio en memoria y se realizan las acciones
necesarias para inicializarlo. Esto tiene un coste en tiempo de ejecución pero
mucho menor que el coste de ejecución que ocurre cuando un programa llama
a otro programa.
Programa ILE

Es un objeto en el sistema operativo (*PGM). Resulta de "unión" (link) de uno o


varios módulos y opcionalmente programas de servicio. Es el objeto ejecutable.

Programa

Un programa tiene un punto de acceso que la rutina principal por donde


comienza la ejecución del programa. Cuando se ejecuta el programa, revisa que
los programas de servicio que tuviera asociado son correctos y entonces
comienza la ejecución del programa por la rutina de entrada al programa. Desde
esta rutina se pueden ejecutar otras rutinas o componentes internos de ese
modulo u otros módulos que estén unidos al programa o ejecutar rutinas o
componentes externos que estén en programas de servicio.

A tener en cuenta

Después de explicar lo que son cada una de las partes que componen ILE es
necesario recordar las siguientes características:

 Utilizar componentes para encapsular funcionalidades con un alcance


determinado. Hay que gestionar correctamente los parámetros para facilitar el
mantenimiento.
 Los componentes reutilizables en varios programas deberían encapsularse
en módulos dentro de programas de servicio.
 Un módulo que deba estar en varios programas deberían incluirse en un
programa de servicio.
 Los programas de servicio son capaces de gestionar diferentes "versiones"
a través de la signatures.
 Las llamadas entre módulos se resuelve en tiempo de compilación por lo
que cuando se ejecutan no necesitan tiempo adicional al que sería necesario si
fueran antiguas rutinas.
 Las llamadas a programas de servicio son resueltas en tiempo de
ejecución por lo que tienen cierto coste en tiempo de ejecución pero no llegan
al coste que sería necesario para llamar de un programa a otro programa.
En los próximos artículos trataremos una estrategia de diseño que utilizo para
reducir tiempo de desarrollo y costes de mantenimiento.