El bind es un proceso por el que debe pasar todo programa COBOL z/OS que contenga instrucciones SQL. Se trata de una particularidad del mundo mainframe que llama la atención de muchos novatos, que se hacen la siguiente pregunta: ¿por qué es necesario este proceso y no se genera el ejecutable DB2 directamente en la compilación como en otras plataformas?
Para responder a esta pregunta debemos remontarnos a los inicios del DB2 para MVS (la base del sistema operativo que posteriormente evolucionaría a 0S/390 y z/OS). En aquellos tiempos era habitual que hubiera máquinas separadas para desarrollo y producción. La de desarrollo solía tener licencia de COBOL, pero no de DB2; y la de producción solo licencia de DB2. Por ello hubo que desarrollar un sistema que permitiera hacer las compilaciones de COBOL y DB2 de forma separada.
Este peculiar proceso de compilación de los programas COBOL con DB2 en diferentes fases se mantiene actualmente y vamos a describirlo a continuación.
PRECOMPILACION
En primer lugar, dentro del JCL de compilación se ejecuta un proceso denominado precompilación, que realiza las siguientes acciones:- Una verificación sintáctica sencilla de las sentencias SQL utilizando las DCLGEN incluidas en el programa. La verificación consiste en comprobar que los nombres de campos y tablas de las sentencias están definidos en la DCLGEN.
- Sustituye las sentencias SQL del programa fuente por llamadas al módulo de interfase con DB2, que sí pueden ser traducidas por el compilador.
- Mueve las sentencias SQL extraídas del programa al DBRM: un miembro con en nombre del programa que se crea en la librería DBRMLIB propia del subsistema DB2 que estemos utilizando.
COMPILACION
Una vez extraídas las sentencias DB2, el programa COBOL puede pasar por la compilación y link-edición, que generarán el código ejecutable en la librería correspondiente. Este ejecutable lleva un timestamp asociado que es idéntico al del DBRM generado en la precompilación. Dicho timestamp es muy importante para relacionar un programa COBOL con su parte DB2 en tiempo de ejecución; volveremos más adelante sobre este punto.
BIND
Después de la precompilación y la compilación, para que nuestro programa pueda acceder a DB2 debemos ejecutar el proceso de bind. El resultado del proceso dependerá del tipo de bind que ejecutemos y las opciones son dos: BIND PLAN y BIND PACKAGE (paquete). Las diferencias entre los dos tipos son bastante profundas, así que los trataremos por separado.
BIND PACKAGE
Es el tipo de bind que se utiliza para generar los paquetes (packages) que contienen el código ejecutable de un programa con DB2. Los paquetes pueden agruparse en colecciones (collections). Dentro del proceso de bind se realizan las siguientes acciones:
- Comprobar que nuestro usuario tiene permisos tanto para realizar el bind como para ejecutar las sentencias SQL del DBRM.
- Una verificación sintáctica completa de las sentencias SQL contra el catálogo de DB2.
- La generación del código ejecutable correspondiente a las sentencias SQL del DBRM. Para ello se analizan todas las sentencias y para cada una de ellas se elige el camino de acceso menos costoso en términos de uso de CPU y número de operaciones de entrada/salida.
La salida del proceso es un paquete, que puede estar contenido en una colección o no.
BIND PLAN
Tipo de bind que se emplea con los programas batch que se ejecutan directamente en un JCL y los programas online asociados a una transacción. Dichos programas pueden tener sentencias SQL o no (lo más habitual actualmente es que no las tengan).
Como párametros de entrada al proceso tendremos que indicar las ubicaciones en las que el sistema debe buscar los ejecutables DB2 de toda la unidad de ejecución (programa principal y subprogramas). Para ello debemos indicar los nombres de colecciones y/o paquetes involucrados. Es requisito previo haber realizado el BIND PACKAGE de los DBRM en cuestión.
La salida del proceso es un plan: objeto que contiene información sobre las dependencias DB2 del programa.
Nota: antes de la introducción de los paquetes, los BIND PLAN eran diferentes; dentro del plan se incluía todo el código ejecutable DB2, tanto de los DBRM del programa principal como de los subprogramas llamados. Por ejemplo, para un programa A con DB2 que llamara a un programa B con DB2, que a su vez llamara a otro programa C con DB2, la entrada al bind eran los DBRM de los tres programas. Este es ejemplo sencillo, pero en casos de cadenas de llamadas complejas con cientos de subprogramas, la modificación de uno solo de ellos obligaba a hacer de nuevo el BIND PLAN de todos los DBRM. Este problema se solucionó con la llegada de los paquetes.
TIEMPO DE EJECUCIÓN
En los apartados anteriores hemos visto que como resultado de todo el proceso tenemos tres elementos: el ejecutable del programa, el plan y los paquetes referenciados por el plan. A continuación vamos a ver cómo interviene cada uno de ellos en tiempo de ejecución y cómo se utiliza el timestamp que mencionamos en el apartado de la compilación. Para ello usaremos un ejemplo.
Supongamos que se va a ejecutar un programa batch PGM1 (sin DB2), que llama a PGM2 (con DB2) y PGM3 (con DB2).
Previamente tendremos que haber hecho:
- Precompilación y compilación de PGM1, PGM2 y PGM3.
- BIND PACKAGE de PGM2 incluyéndolo en la colección PGMCONTA.
- BIND PACKAGE de PGM3 incluyéndolo en la colección PGMLISTAD.
- BIND PLAN de PGM1 incluyendo las colecciones PGMCONTA y PGMLISTAD.
En tiempo de ejecución, DB2:
- Buscará un paquete PGM2 en PGMCONTA con el mismo timestamp que la colección del programa y lo encontrará.
- Buscará un paquete PGM3 en PGMCONTA con el mismo timestamp que la colección del programa y no lo encontrará; continuará la búsqueda en PGMLISTAD y sí lo encontrará.
En este ejemplo todo iría bien y las sentencias DB2 podrían ejecutarse. Desgraciadamente no siempre ocurre así y es muy habitual encontrarnos con un SQLCODE -805 al ejecutar un programa con DB2. Este error se produce cuando DB2 no consigue encontrar alguno de los paquetes.
Volviendo al ejemplo anterior, obtendríamos un SQLCODE -805 en este caso:
Compilamos PGM2, pero no hacemos el BIND PACKAGE; la compilación ha generado un nuevo timestamp. El paquete PGM2 sigue existiendo en la colección PGMCONTA, pero con un timestamp diferente. Por tanto, al ejecutar el programa la búsqueda del paquete fallará con un -805.