lunes, 26 de enero de 2015

Lenguaje Binder.

En la entrada "Lenguaje Binder. Características y estrategias" anterior os presenté las características generales y estrategias en la creación de programas de servicio y el sentido de la signature. 
Ahora en esta entradas os explicaré los comandos del lenguaje binder. 

El código fuente binder se almacena en un miembro de un archivo de fuentes y el tipo de fuente es BND. En este fuente se almacenan las exportaciones de componentes que se incluirán en el programa de servicio cuando se compile. Este archivo no se compila; se utiliza en la creación del programa de servicio.


Creación de un programa de servicio

A la hora de crear un programa de servicio y en relación con las exportaciones que se incluirán en un programa de servicio existen dos posibilidades en el comando de creación (CRTSRVPGM):
  • Indicarle el miembro fuente donde está la definición de exportaciones a través del binder
Exportar . . . . . . . . . . . . EXPORT         *SRCFILE    
Exportar archivo fuente  . . . . SRCFILE        ArchivoFuente    
  Biblioteca . . . . . . . . . .                  Biblioteca
Exportar miembro fuente  . . . . SRCMBR         Miembro   
  • Indicarle que no existe miembro fuente y que recoja todas las exportaciones que están indicadas en el módulo o módulos que se van a enlazar en el programa de servicio.
Exportar . . . . . . . . . . . . EXPORT         *ALL_____    
Exportar archivo fuente  . . . . SRCFILE        ________    
  Biblioteca . . . . . . . . . .                  _________
Exportar miembro fuente  . . . . SRCMBR         ________



Personalmente utilizo la primera para poder tener control sobre las diferentes signatures que tenga y permita un programa de servicio. 


Binder. Definición de componentes exportables

Para facilitar la comprensión vamos a exponer un ejemplo sobre el que posteriormente crearemos el fuente Binder. Supongamos que tenemos un módulo que vamos a enlazar en un programa de servicio y en ese modulo tenemos tres componentes exportables (calcPrecio, calcDescuento, calcImpuesto) y un componente interno no exportable (convMoneda)

En el miembro Binder pondremos los componentes exportables de TODOS los módulos que compondrán el programa de servicio. Sobre el ejemplo anterior el miembro contendrá:

/*  Comentarios                                               */
/*                                                            */
          STRPGMEXP  PGMLVL(*CURRENT) LVLCHK(*YES)              
             EXPORT     SYMBOL(calcPrecio)                    
             EXPORT     SYMBOL(calcDescuento)                    
             EXPORT     SYMBOL(calcImpuesto)                    

          ENDPGMEXP                                             

Entre STRPGMEXP y ENDPGMEXP se podrán todos los componentes exportables bajo el código EXPORT.

STRPGMEXP tiene dos parametros. El primero (PGMLVL) lo veremos a continuación y el segundo LVLCHK(*YES) le indica al programa de servicio que cuando un ejecutable utilice este programa de servicio compruebe la Signature del programa de servicio con la que tiene almacenada el programa ejecutable y que se tomó en el momento de compilación. Esto sirve para que el SO entienda que no hay problema en utilizar el programa de servicio por el programa ejecutable que lo intenta utilizar.
Con /* */ podremos poner los comentarios que queramos.

Imaginemos que al compilar el programa de servicio SRVPGM1 con este binder, se genera una signature X1. 
Posteriormente se compilar dos programas PGM1 y PGM2 que se enlazan con ese programa de servicio por lo que en la definición de esos dos programas podremos comprobar que se enlazaron con la signature X1 del programa de servicio.


Binder. Añadir un nuevo componente

Aquí vamos a mostrar como añadir nuevos componentes SIN tener que recompilar todos los programas que ya están enlazados con el programa de servicio.

Supongamos que ahora en el módulo hemos añadido un componente exportable más (calcMargen). Tendremos que modificar el miembro binder y compilar el programa de servicio PERO lo que deseamos es que no tengamos que volver a compilar todos los programas que ya estaban utilizando ese programa de servicio. 
Eso lo facilita las signatures y el lenguaje Binder. Lo haremos de las siguiente forma:


          STRPGMEXP  PGMLVL(*CURRENT) LVLCHK(*YES)              
             EXPORT     SYMBOL(calcPrecio)                    
             EXPORT     SYMBOL(calcDescuento)                    
             EXPORT     SYMBOL(calcImpuesto)                    
             EXPORT     SYMBOL(calcMargen)                    

          ENDPGMEXP   

          STRPGMEXP  PGMLVL(*PRV) LVLCHK(*YES)              
             EXPORT     SYMBOL(calcPrecio)                    
             EXPORT     SYMBOL(calcDescuento)                    
             EXPORT     SYMBOL(calcImpuesto)                    

          ENDPGMEXP   

Sobre el contenido del miembro binder anterior hemos añadido un nuevo grupo de entradas y hemos modificado la entrada anterior poniendo *PRV. Este parámetro se refiere únicamente a que es una versión anterior (puede haber tantas como versiones haya tenido el programa de servicio) y *CURRENT identifica la versión actual.

En las lineas antiguas cambiaremos *CURRENT por *PRV y crearemos un nuevo conjunto con la expresión *CURRENT y que contenga todos los componentes anteriores más los que hayamos añadido nuevos (calcMargen). Es necesario que los nuevos componentes se añadan al final para que no haya que recompilar todos los programas que enlazaron la versión anterior del programa de servicio.

Siguiendo con el ejemplo, al compilar el programa de servicio SRVPGM1 tendremos que tiene la signature X2 y X1 (la anterior).
Los programas antiguos PGM1 y PGM2 que tenían la signature X1 siguen funcionando correctamente sin tener que volver a compilarlo.
Ahora se compila un nuevo programa PGM3 y en este caso al enlazarlo al programa de servicio, recogerá la signature X2 del programa de servicio.  
Y todos los programas funcionan perfectamente!!!!!


Es la gran ventaja de los programas de servicio. Podremos añadir funcionalidades nuevas (y hacer determinados cambios) que hacen que todos los programas que los utilizan no haya que recompilarlo... (lógicamente teniendo un poquito de cuidado con el orden de componente exportables y con los parámetros de los componentes exportables).

Binder. Eliminar un componentes exportables sin recompilar programas

Aquí vamos a mostrar como eliminar un componentes SIN tener que recompilar todos los programas que ya están enlazados con el programa de servicio. No sería la mejor opción pero podría ser útil en el caso de que tengamos un programa de servicio con muchísimos programas que lo utilicen y no queramos (o no podamos) compilarlos.

El objetivo es que no cambien las signatures. Para ello, simplemente dejaremos el componente (con sus parámetros de entrada y salida) pero le "limpiaremos" el código, es decir, no hará nada. Aún así, se supone que no hay ningún programa que utilice ese componente. En el fuente binder dejaremos el componente en la misma posición. De esta forma al no eliminar el componente, no se cambiarán las signatures.










No hay comentarios:

Publicar un comentario