IDUG Content Committee

Nota del editor: Este artículo fue publicado originalmente en inglés. Con la aprobación del autor, el equipo de IDUG ha creado la traducción que a continuación se presenta.

Este artículo explora las configuraciones que pueden tomar ventaja del esquema de entrega continua de Db2 para z/OA cuando las aplicaciones dinámicas de SQL están utilizando conexiones JDBC de tipo 4. Existen muchas variantes en las maneras en las que pueden configurar el conector y el servidor, de manera que ésta podría no ser una descripción que cubra todas las posibilidades, pero esperamos que pueda guiarlos mientras ustedes establecen sus propias políticas para administrar múltiples aplicaciones y varios Niveles de Función (Function Level) del servidor. La intención es ofrecer una vista de despliegue de aplicaciones sobre un entorno con muchas aplicaciones.

Entrega Continua (Continuous Delivery) y Db2 para z/OS

Es preferible que este no sea el primer artículo que leen sobre Db2 para z/OS y Entrega Continua. Primero deberían familiarizarse con el concepto de compatibilidad de aplicaciones (application compatibility). Los mejores recursos se listan a continuación (ligas en inglés):

Exploring IBM Db2 for z/OS Continuous Delivery Redpaper by Chris Crone

IDUG Blog: DB2 CONTINUOUS DELIVERY – SAFELY MANAGING CHANGE by Chris Crone

Db2 12 Migration and Continuous Delivery de David Simpson

Db2 12 and the IBM Data Server Drivers with FL 501 and Above de Chris Crone

Una de las cosas a observar aquí es que la entrega continua de nuevas funciones en Db2 para z/OS significa nuevos Niveles de Función. Una vez instalados y activados, se tendrá disponible un nuevo Nivel de Función habilitado para las aplicaciones con base en la configuración de compatibilidad de aplicaciones. Los Niveles de Función disponibles hasta el momento incluyen:

• V10R1 – Compatibilidad con versión 10
• V11R1 – Compatibilidad con versión 11
• V12R1M500 – Funcionalidad base de Db2 12
• V12R1M501 – Compatibilidad con versión 12 Nivel de Función 1
• V12R1M502 – Compatibilidad con versión 12 Nivel de Función 2
• V12R1M503 – Compatibilidad con versión 12 Nivel de Función 3, que es el nivel más alto hasta el momento

IBM Data Server Driver

El conector Data Server Driver para JDBC y SQLJ generalmente es compatible con una versión superior, es decir, con la siguiente versión de Db2, y tal vez es posible con mayores versiones, pero sólo si el conector no utiliza nuevas funcionalidades. De esta manera, cualquier nivel de conector que estuvieran utilizando para conectarse a Db2 11 para z/OS debería funcionar. Sin embargo, es aconsejable que actualicen el conector IBM Data Server Driver, especialmente si desean tomar ventaja de nuevas funcionalidades y nuevas características. Para comenzar a utilizar nuevas funciones de Db2 12 para z/OS con un Nivel de Función M501 y superiores, necesitan asegurarse de que su conector IBM Data Server Driver tenga un nivel mínimo de 3.72.30 para JDBC 3.0 (la funcionalidad hacia adelante de JDBC 3.0 está deprecada así que estamos suponiendo compatibilidad hacia V12R1M500), o también puede encontrarse en nivel 4.22.42 para JDBC 4.0. Esto corresponde a Db2 v11.1 M2 FP2. Hasta este momento, les recomiendo ampliamente el conector más reciente que es Db2 V11.1 M4 FP4 debido a que se han aplicado varias mejoras.

Definiciones típicas de conexiones JDBC tipo 4 en Db2 para z/OS

Durante muchos años he observado la proliferación de aplicaciones Java de todo tipo conectándose a Db2 para z/OS y procesando datos. En casi cada caso la conexión es simple, por ejemplo:

jdbc:db2://my.datacerter1.com:446/DB2A:user=bob;password=rady;retrieveMessagesFromServerOnGetMessage=true;

Lo anterior provee una conexión por default a Db2 para z/OS, la cual utiliza un conjunto de paquetes en la colección NULLID que comienza con las siglas SYS*. La colección NULLID generalmente contiene todos los paquetes para todos los clientes remotos que se conectan a Db2 para z/OS. Ahora, existen muchos paquetes en la colección NULLID, los cuales son utilizados para una colección en particular dependiendo de las propiedades adicionales que se hayan configurado.

Sin embargo, en la mayoría de los casos, dichas propiedades adicionales no son utilizadas por los desarrolladores. Existe una compatibilidad de aplicaciones (application compatibility) asociada con estos paquetes NULLID, que se introdujo en Db2 11 para z/OS, y al momento de migración hacia Db2 12 para z/OS este valor debería mantenerse idéntico a como estaba en Db2 11 para z/OS, ya sea V10R1, V11R1 o un string vacío (y esto equivale a V10R1).

En muchos sitios hay múltiples aplicaciones conectándose a Db2 para z/OS en donde todas utilizan el mismo string de conexión para proveer una definición genérica y universal a través de la empresa. En algunos casos, esto significa cientos de aplicaciones utilizando los paquetes NULLID al mismo tiempo. He visto situaciones en donde los parámetros de BIND fueron cambiados a valores específicos sobre los paquetes básicos NULLID debido a que una aplicación en particular necesita utilizar funciones específicas de Db2 pero querían evitar utilizar el configurar las propiedades necesarias en la aplicación.

Qué fue lo que cambió en V12?

Con Db2 12 para z/OS viene un cambio en las responsabilidades sobre la administración de la compatibilidad utilizada para una aplicación. Mientras que el concepto de compatibilidad de aplicaciones existía en Db2 11 para z/OS, generalmente estaba controlada por los administradores del sistema y DBAs para los paquetes NULLID. Moviéndonos hacia adelante será la responsabilidad de los desarrolladores en conjunto con los DBAs y administradores del sistema comenzando en el nivel de compatibilidad M501. Este control viene en la forma de la columna APPLCOMPAT en la tabla del catálogo SYSIBM.SYSPACKAGE. Actualmente puede configurarse a través del parámetro de BIND APPLCOMPAT, o si están utilizando la utilería DB2Binder entonces esta propiedad se indica en la opción -bindoptions bajo el nombre APPLCOMPAT. Los valores que pueden configurar son exactamente los mismos que los Niveles de Función mencionados en la sección anterior de este artículo. También pueden ejecutar REBIND sobre paquetes ya existentes para modificar el valor de compatibilidad de aplicaciones. Sin embargo, conforme vayan aprendiendo estos cambios deben ser cuidadosamente coordinados y probados, especialmente para los paquetes de la colección NULLID.

¿Y qué significa esto para nuestras aplicaciones dinámicas de JDBC tipo 4? Podría no significar nada o podría hacer una gran diferencia. Cuando migran a Db2 12 para z/OS, tal vez no estén haciendo cambios en los paquetes NULLID y tienen el Nivel de Función global con un valor de V12R1M100. Conforme realicen sus pruebas y tengan más confianza en sus operaciones normales de Db2, podrían decidir activar un nuevo Nivel de Función y elijan moverse a V12R1M500 (a través del comando -ACTIVATE NEW FUNCTION LEVEL) y así el valor se propaga a todo el subsistema. Si, por ejemplo, el nivel de compatibilidad de aplicaciones de sus paquetes NULLID estaba en V11R1 entonces sus aplicaciones JDBC tipo 4 todavía están siendo gobernadas por las reglas de V11R1. Si fueran a ejecutar REBIND sobre estos paquetes con un valor para APPLCOMPAT de V12R1M500, todas sus aplicaciones JDBC tipo 4 estarían inmediatamente en modo Db2 12.

El cambio de responsabilidades sucede al activar V12R1M501. Una cosa por seguro es que al momento de activar el nivel V12R1M501 a nivel de sistema es tiempo de poner atención y cuidado a la compatibilidad de aplicaciones. Si no fueran a hacer nada con sus aplicaciones JDBC tipo 4 y simplemente ejecutaran REBIND a los paquetes NULLID con APPLCOMPAT de V12R1M501, las conexiones al servidor podrían dejar de funcionar por completo! Debido a esto, si al menos una de sus aplicaciones JDBC tipo 4 deseara tomar ventaja de alguna nueva característica de Db2 para z/OS en o superior al nivel M501, deben coordinarse con cualquier parámetro de nivel de función para esta aplicación con el conector IBM Data Server Driver para clientes específicos. Esto es controlado a través de dos propiedades de conexión JDBC:

clientApplcompat – El mínimo nivel de compatibilidad de aplicaciones que el cliente utilizará al hablar con el servidor.

currentPackageSet – El id de colección para los paquetes JDBC que el cliente utilizará al hablar con el servidor.

Tomen nota de los nombres de estas propiedades, especialmente en la combinación de mayúsculas. IBM documenta estos parámetros de varias maneras, pero la manera en que se presentan aquí es correcta para JDBC (pero en ODBC y CLI es diferente). Lo que esto significa es que los desarrolladores, DBAs, y posiblemente los administradores del sistema necesitan estar involucrados en el control de la compatibilidad de aplicaciones a nivel de aplicaciones individuales. Más sobre esto en las siguientes secciones.

¿Qué es la Compatibilidad de Aplicaciones para IBM Data Server Driver?

Si vamos a tener que configurar la compatibilidad de aplicación para nuestras aplicaciones JDBC tipo 4, ¿exactamente qué le estamos diciendo al servidor Db2 12 para z/OS? La respuesta es que estamos indicando que la aplicación va a utilizar una colección específica para comunicarse con el servidor, y que la compatibilidad de aplicaciones (APPLCOMPAT) dentro de los paquetes de dicha colección serán utilizados para determinar el nivel de compatibilidad de la aplicación. El parámetro clientApplcompat es meramente un switch que causa que el conector mencione el nombre de la conexión al momento de conectarse. Entonces el servidor carga los paquetes para dicho ID de colección, y envía el nivel de APPLCOMPAT desde SYSIBM.SYSPACKAGES de regreso hacia el cliente. Si desde el cliente no se ha especificado ningún valor para currentPackageSet, entonces se utiliza la colección por default NULLID. Para reiterar, el nivel de APPLCOMPAT de los paquetes es el que determina la compatibilidad de aplicaciones para una aplicación en específico, sin importar el valor de clientApplcompat siempre y cuando sea un valor legítimo del mismo nivel o inferior a aquél de APPLCOMPAT en los paquetes. Veamos un ejemplo:

La aplicación “Clientes” ha decidido que necesita utilizar la función LISTAGG en su siguiente versión. Hasta este momento han utilizado la definición por default para sus conexiones hacia Db2. Cuando intentaron utilizar la función LISTAGG recibieron un código SQLCODE -4700 dado que intentaron utilizar una función que no está disponible (la colección NULLID se encuentra con un APPLCOMPAT de V12R1M500). De esta manera, se genera un nuevo conjunto de paquetes de IBM Data Server Driver con un nombre de colección COLLIDV12R1M501 con un APPLCOMPAT de V12R1M501. IBM provee dos juegos de JCLs, DSNTIJLC y DSNTIJLR, que proveen de BINDs y REBINDs para colecciones con un nuevo nivel de APPLCOMPAT. La cadena de conexión se modifica para la aplicación de forma que tiene lo siguiente:

 Al momento de conectarse, el valor de clientApplcompat provocará que el valor de COLLIDV12R1M501 fluya hacia el servidor, el cual a su vez utilizará los paquetes de dicha colección para procesar los queries de estas conexiones. Dado que la configuración de APPLCOMPAT es V12R1M501 dentro de los paquetes de la colección COLLIDV12R1M501, la aplicación de “Clientes” finalmente podrá utilizar la función LISTAGG. Todas las otras aplicaciones permanecen sin cambios ya que todavía están utilizando la colección NULLID de default y no han establecido otro valor a través del parámetro clientApplcompat.

Registros especiales

Es importante remarcar que los valores de las propiedades del driver clientApplcompat y currentPackageSet no tienen impacto sobre los registros especiales de Db2 CURRENT APPLICATION COMPATIBILITY y CURRENT PACKAGESET. El registro especial CURRENT APPLICATION COMPATIBILITY es determinado por el valor de APPLCOMPAT para el paquete, mientras que el valor de CURRENT PACKAGESET es un string vacío. Cambiar el valor de CURRENT PACKAGESET no tiene impacto si se realiza después de que la conexión se ha realizado aún cuando este mandato no regrese errores. También es necesario mencionar que si la aplicación cambia la colección a usar a través del registro CURRENT PACKAGESET, a partir de ese momento la aplicación obtendrá la compatibilidad de aplicaciones de los paquetes en la colección si dicha colección existe. El registro especial CURRENT APPLICATION COMPATIBILITY reflejará dicho cambio. Sin embargo, una vez aplicado el commit, la colección en uso se restablecerá dependiendo de la conexión a Db2 y cómo es que los threads pasen al pool o sean reutilizados. De esta manera, no es aconsejable utilizar el registro CURRENT PACKAGESET para cambiar la colección en uso.

Cambiar el valor de CURRENT APPLICATION COMPATIBILITY fallará si el nivel de función es mayor al nivel soportado por los paquetes en la colección. Por otro lado, cambiar el valor a un nivel más bajo podría limitar la funcionalidad de los mandatos ejecutados.

Ajustando las propiedades del conector (driver)

• Las propiedades para el conector IBM Data Server Driver pueden ser ajustadas en el string de conexión, y generalmente esto es suficiente para muchas aplicaciones. Sin embargo, en entornos con un equipo de desarrollo grande o en situaciones donde existe una gran nivel de automatización al ensamblar las aplicaciones, sería necesario contar con más alternativas. La documentación para el desarrollo de Java en Db2 parece señalar, aunque vagamente, que las propiedades del conector pueden ajustarse de varias maneras:
• - Dentro del contenedor Java o servidor web.
• - Servicios batch o en línea
• - Openshift en AWS
• - Muchas otras alternativas
• Los componentes de la aplicación se almacenan en librerías compartidas con control de versiones, y se ensamblan con tecnologías como Git, Maven o Jenkins. Para administrar efectivamente lo que se convertirá en una librería de versión de IBM Data Server Driver y su nivel correspondiente de compatibilidad de aplicaciones, es importante hacerlas seleccionables como en Maven. Debido a esto, es importante poder administrar las combinaciones de propiedades en un archivo (especialmente cierto para propiedades como clientApplcompat y currentPackageSet).
• Al momento de probar esta metodología solo hemos sido capaces de configurar la propiedad currentPackageSet en un archivo DB2JccConfiguration.properties. IBM ha indicado que a partir de la versión Db2 v11.1 M4 FP4 la propiedad clientApplcompat se podrá configurar en un archivo DB2JccConfiguration.properties, lo cual está disponible desde el 27 de Noviembre de 2018. No hay una mención clara de qué propiedades podrían ser ajustadas dentro de un archivo JAR, y aparentemente la documentación está incompleta en este punto. De este modo, la manera apropiada para administrar y desplegar las propiedades para aplicaciones en específico siguen siendo un tema de investigación para los equipos de desarrollo involucrados. Otra posibilidad es que los parámetros del datasource sean inyectados a Jenkins (o algún similar) como parte del despliegue, pero esto también está siendo explorado

Para enfatizar el punto en configurar las propiedades, los desarrolladores de aplicaciones no están particularmente interesados en qué base de datos se trabajará. Ellos conocen los requerimientos y los datos, y en su despliegue se encuenra todo lo que podrían necesitar: El servidor web, componentes open source, código compartido, conectores. Ellos van a tener menor interés sobre el nivel de servicio de una base de datos, y configurar las propiedades de la manera más transparente posible es muy importante.

Configuraciones posibles para Driver/Servidor

Desde la perspectiva del servidor de datos, es aparente que necesitamos administrar las combinaciones posibles del conector (driver) y de los niveles de función del servidor. Esto puede ser hecho en cada nivel de granularidad, desde algo tan pequeño como uno por aplicación hacia uno a nivel de la empresa. De un lado del espectro tenemos una aplicación CLIENTE. La aplicación fue desarrollada utilizando el nivel de Db2 V12R1M501 y dentro del conector IBM Data Server Driver la propiedad clientApplcompat tiene un valor de V12R1M501 y CLIENTE para la propiedad currentPackageSet. Del lado del servidor la colección se copia de la base NULLID hacia CLIENTE utilizando el JCL DSNTIJLC. Esto da completa flexibilidad para cambiar la compatibilidad de aplicaciones (siempre y cuando sea hacia un nivel mayor) de la aplicación CLIENTE simplemente al aplicar rebind sobre los paquetes en la colección CLIENTE. Entonces, podemos actualizar el nivel de función sobre la aplicación CLIENTE sin impactar ninguna otra aplicación. Por supuesto, esto significa una colección para cada aplicación y esto podría resultar en una pesadilla para administrar. Del otro lado podría haber solo una colección NULLID. Podría haber una gran responsabilidad en todas las aplicaciones al configurar clientApplcompat en coordinación con una actualización al nivel de función V12R1M501 y más allá y un REBIND de los paquetes NULLID hacia un nivel mayor. Para ir hacia adelante, podría ser una práctica usual el incluir nuevos niveles de función al ejecutar REBIND sin actualizar clientApplcompat hasta que una nueva función requiera una actualización del conector.

También existe un punto medio. Una vez que la migración hacia Db2 12 para z/OS se complete, los paquetes NULLID pueden ser actualizados el nivel V12R1M500 sin ningún impacto a las aplicaciones existentes que fueron creadas con un APPLCOMPAT de V11R1 (y se requeriría de pruebas para los paquetes que se generaron con APPLCOMPAT V10R1 antes de moverse a V12R1M500). Entonces, para ir hacia adelante podrían haber colecciones compartidas y configuraciones del conector compartidas (preferentemente con algo parecido a Maven) para los varios niveles de función:

• La colección NULLID con APPLCOMPAT de V12R1M500. Esto significa el nivel default para todo el sistema.
• Una colección de nombre COLLIDV12R1M501 con APPLCOMPAT de V12R1M501, clientApplcompat=V12R1M501, y currentPackageSet=COLLIDV12R1M501 (también podría funcionar con clientApplcompat=V12R1M500, pero la compatibilidad de aplicaciones estará a V12R1M501)
• Una colección de nombre COLLIDV12R1M502 con APPLCOMPAT de V12R1M501, clientApplcompat=V12R1M502, y currentPackageSet con valor COLLIDV12R1M502 (y similar al punto anterior, también se puede con clientApplcompat=V12R1M501 o V12R1M501 pero la compatibilidad de aplicaciones será de V12R1M502).
• Una colección de nombre COLLIDV12R1M503 con APPLCOMPAT de V12R1M503, clientApplcompat a V12R1M503 y currentPackageSet con COLLIDV12R1M503 (y clientApplcompat puede funcionar con valores de V12R1M501, V12R1M502 o V12R1M503 pero la compatibilidad de aplicaciones estará a V12R1M503).

¿Qué solución funciona mejor?

Como siempre, depende de sus estándares y prácticas y de la necesidad del grupo de desarrolladores para utilizar nueva funcionalidad de la base de datos.

• Podrían poner el último nivel de función para la colección de default. Sin embargo, eso requeriría que sus aplicaciones utilicen clientApplcompat una vez que lleguen al nivel de función V12R1M501. Entonces, para avanzar sería muy parecido a una migración de versión de Db2 como se hacía en el pasado.
• Podrían sencillamente dejar el valor en la colección de default a un pre-Db2 12 y continuar hasta que se requiera una nueva función.
• Podrían implementar una estrategia como se mostró anteriormente y tener un plan listo para elegir. Si desean una actualización a un nuevo nivel de compatibilidad de aplicaciones, pueden cambiar las propiedades de conexión. Esto provee un buen nivel de flexibilidad, pero entonces tienen una colección por nivel de compatibilidad de aplicaciones (y también podrían saltarse niveles).
• Podrían crear una colección para cada aplicación, lo cual provee el máximo nivel de flexibilidad, pero podría convertirse en un problema en la administración si se tiene un gran número de aplicaciones.

Otras conexiones de Data Server Driver

Esto solamente cubre las conexiones de JDBC tipo 4 hacia Db2 para SQL dinámico. Para conexiones de JDBC tipo 2 parece que el nivel de compatibilidad de aplicaciones se tomará de los paquetes utilizados sin importar la configuración de la propiedad clientApplcompat (y tampoco importa si la propiedad no se usa), esto es al menos en la colección de default NULLID, lo que incluye APPLCOMPAT en nivel V12R1M501 y superior. Aplicaciones SQLJ funcionarán al nivel de sus paquetes estáticos.

Resumen

La planeación y coordinación de la compatibilidad de aplicaciones con el esquema de entrega continua de Db2 puede tener un gran impacto sobre el desarrollo y el despliegue de sus aplicaciones. Es necesario un buen nivel de entendimiento y cuidado en la planeación para tener una fácil transición, sin embargo, no es algo que puedan ignorar a menos que solamente deseen trabajar con el nivel V12R1M500.