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.
por: Chris Crone, Sarbinder Kallar – IBM SVL Lab
Db2 12 ha estado disponible por cerca de 2 años y muchos clientes han migrado a Db2 12 en Nivel de Función (Function Level) 500. El Nivel de Función (FL) 500 habilita todas las nuevas características base de Db2 12 y es equivalente a lo que anteriormente conocíamos como New Function Mode (NFM) en DB2 11 y anteriores. Ahora que los clientes están en FL 500, están comenzando a pensar en FL 501 y superiores. FL 503 se liberó el 21 de septiembre – para más información sobre este Nivel de Función FL 503 pueden entrar a esta liga en inglés:
https://www.ibm.com/developerworks/community/blogs/897a7c98-57af-4523-9cfa-07ebc3f996b4/entry/Db2_12_FL_503?lang=en
No se requirieron cambios en los conectores IBM Data Server Driver para explotar Db2 12 FL 500. Sin embargo, sí es necesario realizar cambios a nivel de clientes, y potencialmente en el servidor, para explotar las características de FL 501 y más recientes.
La documentación para FL 501 en IBM Knowledge Center se encuentra aquí:
https://www.ibm.com/support/knowledgecenter/es/SSEPEK_12.0.0/wnew/src/tpc/db2z_fl_v12r1m501.html
Mientras que el IBM Redbook (en inglés) sobre Entrega Continua se encuentra aquí:
http://www.redbooks.ibm.com/abstracts/redp5469.html?Open
Los recursos anteriores contienen una gran cantidad de información sobre la activación de FL 501, así como los requerimientos para explotar FL 501 y superiores.
En esta entrega nos gustaría diseccionar la información que ya se encuentra disponible sobre las acciones que podrían decidir tomar o que deben tomar para migrar a niveles superiores de FL 500.
Para comenzar, podemos decir que si no necesitan que sus aplicaciones exploten FL 501 (o más recientes) – entonces no es necesario realizar cambios en sus aplicaciones (y esto incluye a aplicaciones que acceden a Db2 a través de conectores IBM Data Server Driver) para activar FL 501 y superiores. Es necesario remarcar que nos referimos a que las aplicaciones no estarán explotando las novedades, ya que puede haber nuevas funcionalidades que se habilitan con un FL y que no están relacionadas a aplicaciones (por ejemplo, Db2 AI para z/OS en FL 503), y que esto último podría ser una razón para activar un FL.
La activación de un nuevo Nivel de Función, y su habilitación para explotar un FL (utilizando APPLCOMPAT), son acciones separadas para asegurar que las aplicaciones permanezcan estables a través de Niveles de Función. Activar un FL no expone a las aplicaciones los cambios que ofrece un nuevo FL. En general, también deben ejecutar REBIND sobre un paquete (package) con un FL específico para exponer dicha aplicación a los cambios que contiene el FL en cuestión. Esta separación permite que las aplicaciones puedan ser desarrolladas, probadas y liberadas en un nivel específico de APPLCOMPAT, y que al mismo tiempo permanezcan estables a través de varios Niveles de Función hasta que la aplicación requiera tomar ventaja de nuevas funciones que ofrezca algún APPLCOMPAT.
Clientes con aplicaciones que utilizan los paquetes de IBM Data Server Driver tienen algunas dudas sobre cómo funcionan los Niveles de Función y APPLCOMPAT contra los paquetes NULLID, y qué cambios son requeridos para habilitar a las aplicaciones JDBC y CLI con las nuevas funciones de FL 501 y superiores. Como mínimo para las funciones de FL 501, los siguientes cambios son requeridos para clientes con IBM Data Server Driver y la siguiente especificación de una propiedad (observen los nombres):
- Conectores IBM Data Server Driver for JDBC and SQLJ: Versiones 3.72 y 4.22, o más recientes.
- Propiedad - clientApplcompat = V12R1M500[1]
- Otros clientes y conectores IBM Data Server: Db2 para Linux, UNIX y Windows, Versión 11.1 Modificación 2 Fix Pack 2 o más recientes
- Propiedad – ClientApplCompat = V12R1M5001
Los clientes con Data Server Driver en estos niveles tienen una mejora que les permite enviar el nombre de la colección (collection-id) de los paquetes que desean utilizar en el flujo inicial de conexión. La especificación de la propiedad de cliente applcompat activa esta función. [2]
Db2 12 en FL 501 y más recientes requieren que el collection-id de los paquetes y los conectores IBM Data Server Drivers sea enviado en el flujo inicial de la conexión para paquetes NULLID con un APPLCOMPAT de V12R1M501 y superiores. Si el APPLCOMPAT de los paquetes NULLID es menor a V12R1M501 (y el ID de colección de los paquetes no es enviado – debido a que el APPLCOMPAT del cliente no fue enviado), entonces el paquete se cargará, y si éste se encuentra en V12R1M501 o más reciente, se obtendrá un código SQLCODE -30025.
La práctica recomendada para adoptar un Nivel de Función incluye ejecutar BIND para crear un nuevo conjunto de paquetes NULLID utilizando DSNTIJLR. Para ello la siguiente liga ofrece más información (en inglés).
https://www.ibm.com/support/knowledgecenter/es/SSEPEK_12.0.0/apsg/src/tpc/db2z_samp_dsntijlr.html
Db2 recomienda este procedimiento debido a que permite estabilidad para las aplicaciones que ya utilizan paquetes NULLID. Las aplicaciones que requieren utilizar nuevas funcionalidades pueden ser migradas al nuevo conjunto de paquetes NULLID al utilizar la propiedad clientApplcompat y dicho conjunto de paquetes NULLID con un APPLCOMPAT que corresponda al FL deseado.
Por ejemplo, para una aplicación JDBC que requiere utilizar la función LISTAGG que se encuentra disponible desde FL 501, los clientes deberían utilizar lo siguiente:
- clientApplcompat = V12R1M500 [3]
- currentPackageSet = NULLID_V12R1M501
- Del lado del servidor, utilizarían DSNTIJLR para ejecutar BIND a la colección NULLID_V12R1M501 con APPLCOMPAT(V12R1M501).
Se preguntarán la razón de tanta complejidad. ¿No puedo solamente ejecutar sobre mis paquetes NULLID por default con el APPLCOMPAT actual cada vez que cambio de FL y mis aplicaciones verán los cambios? La respuesta rápida es SÍ, aunque al realizar esto las aplicaciones también estarán expuestas a posibles incompatibilidades que se introduzcan con un nuevo FL.
La acción recomendada es tener un conjunto separado (en una colección) de paquetes NULLID para cada FL que adopten, y de esta manera las aplicaciones que necesiten una nueva función podrán cambiarse de colección para tener las nuevas funciones disponibles, mientras que el resto de las aplicaciones existentes permanecen estables. Si ejecutan REBIND sobre el conjunto default de paquetes NULLID con otro nivel de APPLCOMPAT, podrían afectar sus aplicaciones. Las aplicaciones que anteriormente se ejecutaban sin problemas estarían expuestas a un cambio incompatible al incrementar el APPLCOMPAT, o podrían dejar de funcionar si el APPLCOMPAT se disminuye. En algún momento es posible que deseen tener colecciones múltiples para evitar este problema. Es mejor realizar esto siguiendo un diseño que a una necesidad.
Muchos clientes han preguntado si tienen que cambiar la propiedad applcompat a nivel de cliente cada vez que cambien de Niveles de Función. La respuesta es NO. Cambiar el valor de applcompat en el cliente no será necesario hasta que se presente alguna mejora que requiera cambios a nivel servidor. Un valor mínimo de applcompat en el cliente podría ser necesario para soportar una característica nueva, y estaría claramente documentado cuando dicho requerimiento sea necesario.
Existen varias maneras de establecer valores para ClientApplCompat y packageset para conectores que no son Java:
- Agregar los parámetros clientApplcompat y currentPackageSet en la sección global del archivo db2dsdriver.cfg.
- Agregar los parámetros clientApplcompat y currentPackageSet en la sección de base de datos del archivo db2dsdriver.cfg.
- En la aplicación, especificar las claves clientApplcompat y currentPackageSet en un string de conexión del API de conexión como en la función (de CLI) SQLDriverConnect.
- En los atributos de conexión de la aplicación SQL_ATTR_CLIENT_COMPAT y SQL_ATTR_CURRENT_PACKAGE_SET al utilizar la función (CLI) SQLSetConnectAttr.
Para el conector de Java [4], pueden utilizar los parámetros clientApplcompat y packageset con los siguientes mecanismos:
- En una aplicación, indiquen las propiedades clientApplcompat y currentPackageSet en el URL de conexión dentro del método getConnection de la clase DriverManager. Las propiedades también pueden ser utilizadas como valores de java.util.Properties en el parámetro info del método getConnection de la clase DriverManager.
- En una aplicación, utilicen los métodos setCurrentPackageset y setClientAppcompat de la clase DB2BaseDataSource para establecer los valores deseados.
A continuación tenemos algunos ejemplos y ligas a la documentación sobre la activación de un nuevo FL para el conector No-Java.
Utilizar la clave ClientApplCompat en el archivo dsdriver.cfg para especificar FL V12R1M500 y CurrentPackageSet para indicar la colección a utilizar:
Pueden ejecutar los siguientes comandos desde un shell (Unix/Linux) o desde línea de comandos en Windows donde podrán agregar los parámetros en la sección global del archivo db2dsdriver.cfg para habilitar el FL específico en Db2 para z/OS en ODBC. Sustituyan el FL y el id de colección que deseen antes de ejecutar el comando:
Para agregar los parámetros en la sección global del archivo db2dsdriver.cfg.
db2cli writecfg add -parameter "ClientApplCompat=V12R1M500”
db2cli writecfg add -parameter "CurrentPackageSet=NULLID_V12R1M500"
Para agregar los parámetros a la sección de base de datos del archivo db2dsdriver.cfg.
db2cli writecfg add -dsn SAMPLE -database SAMPLE -host hostname -port 5021
db2cli writecfg add -database SAMPLE -host hostname -port 5021 -parameter "ClientApplCompat=V12R1M500"
db2cli writecfg add -database SAMPLE -host hostname -port 5021 -parameter "CurrentPackageSet=NULLID_V12R1M500"
Para asegurarse de que los parámetros hayan sido agregados de forma correcta, ejecuten lo siguiente:
db2cli validate -dsn SAMPLE
Otra opción es indicar los parámetros en el string de conexión de la aplicación.
SQLAllocenv 1
SQLAllocconnect 1 1
SQLSetConnectAttr 1 SQL_ATTR_CLIENT_APPLCOMPAT V12R1M500 9
SQLSetConnectAttr 1 SQL_ATTR_CURRENT_PACKAGE_SET NULLID_V12R1M500 16
SQLDriverConnect 1 0 "database=SAMPLE;hostname=myhost;port=5021;uid=myuid;pwd=mypwd;protocol=tcpip;" -3 255 SQL_DRIVER_NOPROMPT
SQLAllocStmt 1 1
SQLExecDirect 1 "SELECT CURRENT SCHEMA FROM SYSIBM.SYSDUMMY1" -3 fetch 1
Este bloque de código puede ser guardado en un archivo y ejecutado desde línea de comandos de Db2 utilizando la utilería db2cli (ejemplo, db2cli < test.txt).
Para aplicaciones Java – pueden utilizar los siguientes pasos de ejemplo, junto con las ligas de documentación, para activar un nuevo FL a través de APPLCOMPAT en el conector de java:
Claves de IBM data server driver, “configuration keywords” - https://ibm.biz/BdY3Ni
La interfaz DB2BaseDataSource provee métodos set - https://ibm.biz/BdY3Nq
com.ibm.db2.jcc.DB2BaseDataSource.clientApplcompat
(IBM Data Server Driver for JDBC and SQLJ type 4 connectivity)
com.ibm.db2.jcc.DB2BaseDataSource.currentPackageSet
Pueden utilizar lo anterior para especificar los parámetros de las siguientes maneras:
- Indicar los parámetros en el URL de conexión de la clase DriverManager
String conString = "jdbc:db2://myhost:5021/SAMPLE:currentPackageSet=NULLID_V12R1M500;clientApplcompat=V12R1M500;";
Connection con = DriverManager.getConnection(conString,"myuid","mypwd");
- Especificar los parámetros utilizando los métodos setXXX de la interfaz DB2BaseDataSource.
DB2SimpleDataSource ds = new com.ibm.db2.jcc.DB2SimpleDataSource();
ds.setClientApplcompat("V12R1M500");
ds.setDatabaseName("SAMPLE");
ds.setServerName("myhost");
ds.setPortNumber(5021);
ds.setCurrentPackageSet("NULLID_V12R1M500");
ds.setUser("myuid");
ds.setPassword("mypwd");
Connection con = ds.getConnection();
En resumen, hemos hablado sobre las razones de por qué los nuevos clientes, así como la configuración de dichos clientes, son necesarios para explotar las funciones del esquema de Entrega Continua de Db2. También hemos dado puntos y ejemplos sobre cómo configurar los conectores data server para moverse hacia adelante. Esperamos que esta información les sea útil junto con el artículo de Dan Luksetich localizado en la siguiente liga:
https://www.idug.org/p/bl/ar/blogaid=803
En donde ofrece una pespectiva de usuario sobre este tema, y con ello esperamos que tengan información suficiente para ir hacia adelante en su sitio.
[1] Noten que V12R1M500 es el valor mínimo que puede ser utilizado. Si el valor de APPLCOMPAT de los paquetes NULLID es V12R1M501, clientApplcompat también puede ser V12R1M501. De igual manera, si el valor de APPLCOMPAT de los paquetes NULLID es de V12R1M50x, el valor de clientApplcompat también puede ser de V12R1M50x. Los dos requerimientos básicos son:
- clientApplcompat debe tener un valor de por lo menos V12R1M500.
- clientApplcompat no puede ser mayor que el atributo APPLCOMPAT de los paquetes NULLID.
[2] Observen que en los conectores ODBC/CLI y JDBC la propiedad de applcompat se escribe diferente.
[3] Este valor debe ser por lo menos V12R1M500, pero también podría ser V12R1M501.
[4] Si se encuentran utilizando el conector de tipo 2 en JDBC desde un workstation, el archivo db2dsdriver.cfg puede ser utilizado para indicar estos parámetros.
#espanol