db2a1z90

DB2®

Desarrollo de aplicaciones de SQL incorporado

DB2 Versión 9

para Linux, UNIX y Windows

SC11-3190-00

��

Antes de utilizar esta información y el producto al que da soporte, asegúrese de leer la información general incluida en el

apartado Avisos.

Información sobre la edición

Esta publicación es la traducción del original inglés DB2 Version 9 for Linux, UNIX, and Windows Developing

Embedded SQL Applications, (SC10-4232-00).

Este documento contiene información sobre productos patentados de IBM. Se proporciona según un acuerdo de

licencia y está protegido por la ley de la propiedad intelectual. La presente publicación no incluye garantías del

producto y las declaraciones que contiene no deben interpretarse como tales.

Puede realizar pedidos de publicaciones en línea o a través del representante de IBM de su localidad.

v Para realizar pedidos de publicaciones en línea, vaya a IBM Publications Center en www.ibm.com/shop/publications/order

v Para encontrar el representante de IBM correspondiente a su localidad, vaya a IBM Directory of Worldwide

Contacts en www.ibm.com/planetwide

Para realizar pedidos de publicaciones en marketing y ventas de DB2 de los EE.UU. o de Canadá, llame al número

1-800-IBM-4YOU (426-4968).

Cuando envía información a IBM, otorga a IBM un derecho no exclusivo para utilizar o distribuir dicha información

en la forma en que IBM considere adecuada, sin contraer por ello ninguna obligación con el remitente.

© Copyright International Business Machines Corporation 1993, 2006. Reservados todos los derechos.

http://www.ibm.com/shop/publications/order


http://www.ibm.com/planetwide

Contenido

Parte 1. Desarrollo de aplicaciones

cliente de SQL incorporado . . . . . 1

Capítulo 1. Introducción a SQL

incorporado . . . . . . . . . . . . . 3

Introducción a SQL incorporado . . . . . . . . 3

Incorporación de sentencias de SQL en un lenguaje

principal . . . . . . . . . . . . . . . . 4

Incorporación de sentencias de SQL en un

lenguaje principal . . . . . . . . . . . . 4

Sentencias de SQL incorporado en aplicaciones C

y C++ . . . . . . . . . . . . . . . 5

Sentencias de SQL incorporado en aplicaciones

COBOL . . . . . . . . . . . . . . . 7


FORTRAN . . . . . . . . . . . . . . 8


REXX . . . . . . . . . . . . . . . . 9

Software de desarrollo soportado para aplicaciones

de SQL incorporado . . . . . . . . . . . 12

Configuración del entorno de desarrollo de SQL

incorporado . . . . . . . . . . . . . . 12

Capítulo 2. Diseño de aplicaciones de

SQL incorporado . . . . . . . . . . 15

Diseño de aplicaciones de SQL incorporado . . . 15

Uso de SQL estático . . . . . . . . . . . 16

Uso de SQL dinámico . . . . . . . . . . . 18

Consideraciones sobre autorización para SQL

incorporado . . . . . . . . . . . . . . 19

Ejecución de sentencias de SQL estático y dinámico

en aplicaciones de SQL incorporado . . . . . . 20

Ejecución de sentencias de SQL estático y

dinámico en aplicaciones de SQL incorporado . . 20

Sentencias dinámicas de SQL incorporado . . . 21

Determinación del momento en que deben

ejecutarse sentencias de SQL estática o

dinámicamente en aplicaciones de SQL

incorporado . . . . . . . . . . . . . 22

Rendimiento de aplicaciones de SQL incorporado . 25

Soporte de 32 bits y 64 bits para aplicaciones de

SQL incorporado . . . . . . . . . . . . 26

Restricciones en aplicaciones SQL incorporadas . . 27

Restricciones sobre juegos de caracteres cuando

se utiliza C y C++ para programar aplicaciones

de SQL incorporado . . . . . . . . . . 27

Restricciones en el uso de COBOL para

programar aplicaciones de SQL incorporado . . 28

Restricciones en el uso de FORTRAN para


Restricciones en el uso de REXX para programar

aplicaciones de SQL incorporado . . . . . . 30

Recomendaciones para desarrollar aplicaciones

de SQL incorporado con XML y XQuery . . . . 30

Transacciones simultáneas y acceso a base de datos

de varias hebras en aplicaciones de SQL

incorporado . . . . . . . . . . . . . . 31

Transacciones simultáneas y acceso a base de

datos de varias hebras en aplicaciones de SQL

incorporado . . . . . . . . . . . . . 31

Recomendaciones para utilizar varias hebras . . 34

Consideraciones sobre la página de códigos y el

código de país o región para aplicaciones UNIX

de varias hebras . . . . . . . . . . . . 35

Resolución de problemas de aplicaciones de SQL

incorporado de varias hebras . . . . . . . 36

Capítulo 3. Programación de

aplicaciones de SQL incorporado . . . 39

Programación de aplicaciones de SQL incorporado 42

Archivos fuente de SQL incorporado . . . . . . 43

Plantilla de aplicación de SQL incorporado en C . . 44

Archivos de inclusión y definiciones necesarios para

aplicaciones de SQL incorporado . . . . . . . 47

Archivos de inclusión y definiciones necesarios

para aplicaciones de SQL incorporado . . . . 47

Archivos include para aplicaciones de SQL

incorporado C y C++ . . . . . . . . . . 48


incorporado COBOL . . . . . . . . . . 50


incorporado FORTRAN . . . . . . . . . 53

Declaración de la SQLCA para el manejo de errores 56

Manejo de errores utilizando la sentencia

WHENEVER . . . . . . . . . . . . . . 57

Conexión con bases de datos DB2 en aplicaciones de

SQL incorporado . . . . . . . . . . . . 58

Tipos de datos que se correlacionan con tipos de

datos SQL en aplicaciones de SQL incorporado . . 59


datos SQL en aplicaciones de SQL incorporado . 59

Tipos de datos de SQL soportados en

aplicaciones de SQL incorporado C y C++ . . . 60


aplicaciones de SQL incorporado COBOL . . . 67


aplicaciones de SQL incorporado FORTRAN . . 70


aplicaciones de SQL incorporado REXX . . . . 72

Variables del lenguaje principal en aplicaciones de

SQL incorporado . . . . . . . . . . . . 74

Variables del lenguaje principal en aplicaciones


Declaración de variables del lenguaje principal en


Declaración de variables del lenguaje principal

con el Generador de declaraciones db2dclgn . . 77

© Copyright IBM Corp. 1993, 2006 iii

Tipos de datos de columna y variables del

lenguaje principal en aplicaciones de SQL

incorporado . . . . . . . . . . . . . 77


XML en aplicaciones de SQL incorporado . . . 79

Identificar valores XML en una SQLDA . . . . 80

Identificación de valores de SQL nulos con

variables de indicador de nulo . . . . . . . 81

Inclusión de las variables del lenguaje principal

SQLSTATE y SQLCODE en aplicaciones de SQL

incorporado . . . . . . . . . . . . . 83

Cómo hacer referencia a variables del lenguaje

principal en aplicaciones de SQL incorporado . . 84

Ejemplo: cómo hacer referencia a variables del

lenguaje principal XML en aplicaciones de SQL

incorporado . . . . . . . . . . . . . 85


de SQL incorporado C y C++ . . . . . . . 86

Variables del lenguaje principal en COBOL . . 119

Variables del lenguaje principal en FORTRAN 133


de SQL incorporado REXX . . . . . . . . 142

Ejecución de sentencias de SQL en aplicaciones de

SQL incorporado . . . . . . . . . . . . 150

Ejecución de sentencias de SQL en aplicaciones


Comentarios en aplicaciones de SQL

incorporado . . . . . . . . . . . . . 150

Ejecución de sentencias de SQL estático en


Recuperación de información de variables del

lenguaje principal procedente de la estructura

SQLDA en aplicaciones de SQL incorporado . . 152

Ejecución de expresiones XQuery en


Suministro de entrada de variables a un SQL

ejecutado dinámicamente mediante marcadores

de parámetros . . . . . . . . . . . . 169

Llamada a procedimientos almacenados en


Lectura de los conjuntos de resultados y

desplazamiento por los mismos en aplicaciones


Recuperación de mensajes de error en aplicaciones


Información de error en los campos SQLCODE,

SQLSTATE y SQLWARN . . . . . . . . 190

Recuperación de mensajes de error en


Consideraciones sobre las rutinas de lista de

salida . . . . . . . . . . . . . . . 194

Consideraciones sobre el manejador de

excepciones, señales e interrupciones . . . . 194

Desconexión de aplicaciones de SQL incorporado 195

Capítulo 4. Creación de aplicaciones

de SQL incorporado . . . . . . . . 197

Creación de aplicaciones de SQL incorporado . . 198

Precompilación de aplicaciones de SQL

incorporado con el mandato PRECOMPILE (o

PREP) . . . . . . . . . . . . . . . . 201


incorporado con el mandato PRECOMPILE . . 201


incorporado que acceden a más de un servidor

de bases de datos . . . . . . . . . . . 203

Paquetes de aplicaciones y planes de acceso de

SQL incorporado . . . . . . . . . . . 204

Calificación de esquema de paquete utilizando

el registro especial CURRENT PACKAGE PATH . 204

Indicaciones horarias generadas por el

precompilador . . . . . . . . . . . . 208

Errores y avisos procedentes de la

precompilación aplicaciones de SQL

incorporado . . . . . . . . . . . . . 209

Compilación y enlace de archivos fuente que

contienen SQL incorporado . . . . . . . . . 209

Vinculación de paquetes de SQL incorporado con

una base de datos mediante el mandato BIND . . 210

Vinculación de paquetes de SQL incorporado

con una base de datos . . . . . . . . . 210

Efecto de la opción de vinculación

DYNAMICRULES en SQL dinámico . . . . . 211

Utilización de registros especiales para controlar

el entorno de compilación de sentencias . . . 214

Cómo volver a crear paquetes utilizando el

mandato BIND y un archivo de vinculación

existente . . . . . . . . . . . . . . 214

Revinculación de paquetes existentes con el

mandato REBIND . . . . . . . . . . . 215

Consideraciones sobre la vinculación . . . . 216

Ventajas de la vinculación diferida . . . . . 217

Mejoras en el rendimiento cuando se utiliza la

opción REOPT del mandato BIND . . . . . 218

Almacenamiento y mantenimiento de paquetes . . 219

Almacenamiento y mantenimiento de paquetes 219

Creación de versiones de paquetes . . . . . 219

Resolución de nombres de tabla no calificados 220

Creación de aplicaciones de SQL incorporado

mediante el script de creación de ejemplo . . . . 221


mediante el script de creación de ejemplo . . . 221

Programas de utilidad de comprobación de

errores . . . . . . . . . . . . . . . 223

Creación de aplicaciones y rutinas escritas en C

y C++ . . . . . . . . . . . . . . . 225

Creación de aplicaciones y rutinas escritas en

COBOL . . . . . . . . . . . . . . 246

Creación y ejecución de aplicaciones de SQL

incorporado escritas en REXX . . . . . . . 265


desde la línea de mandatos . . . . . . . . . 268


desde la línea de mandatos . . . . . . . . 268


escritas en C o C++ (Windows) . . . . . . 268

Migración de las aplicaciones de SQL incorporado 269

Restricciones de enlazar a libdb2.so . . . . . . 271

Parte 2. Desarrollo de rutinas

incorporadas . . . . . . . . . . . 273

iv Desarrollo de aplicaciones de SQL incorporado

Capítulo 5. Desarrollo de rutinas

externas . . . . . . . . . . . . . 275

Rutinas externas . . . . . . . . . . . . 275

Visión general de las rutinas externas . . . . . 276

Visión general de las rutinas externas . . . . 276

Funciones de rutinas externas . . . . . . . 276

Características de las funciones y métodos

externos . . . . . . . . . . . . . . 277

API y lenguajes de programación soportados 290

Creación de rutinas externas . . . . . . . 297

Estilos de parámetros de rutinas externas . . . 298

Gestión de bibliotecas o clases de rutinas . . . 301

Soporte de 32 bits y 64 bits para rutinas

externas . . . . . . . . . . . . . . 306

Rendimiento de las rutinas con bibliotecas de 32

bits en servidores de bases de datos de 64 bits . 307

Soporte para el tipo de datos XML en las

rutinas externas . . . . . . . . . . . 308

Restricciones de las rutinas externas . . . . . 309

Creación de rutinas externas . . . . . . . 312

Rutinas C y C++ . . . . . . . . . . . . 314

Rutinas C y C++ . . . . . . . . . . . 314

Soporte para el desarrollo de rutinas externas en

C . . . . . . . . . . . . . . . . 315

Soporte para el desarrollo de rutinas externas en

C++ . . . . . . . . . . . . . . . 315

Herramientas para el desarrollo de rutinas C y

C++ . . . . . . . . . . . . . . . 316

Diseño de rutinas C y C++ . . . . . . . . 316

Creación de rutinas C y C++ . . . . . . . 360

Creación del código de rutinas C y C++ . . . 362

Procedimientos COBOL . . . . . . . . . . 388

Procedimientos COBOL . . . . . . . . . 388

Soporte para el desarrollo de procedimientos

externos en COBOL . . . . . . . . . . 390

Creación de rutinas COBOL . . . . . . . 391

Parte 3. Apéndices . . . . . . . . 403

Apéndice A. Ejemplos de SQL

incorporado . . . . . . . . . . . . 405

Ejemplos de C . . . . . . . . . . . . . 405

Ejemplos de COBOL . . . . . . . . . . . 408

Ejemplos de REXX . . . . . . . . . . . 412

Apéndice B. Información técnica

sobre DB2 Database . . . . . . . . 415

Visión general de la información técnica de DB2 415

Comentarios sobre la documentación . . . . 415

Biblioteca técnica de DB2 en formato PDF . . . . 416

Pedido de manuales de DB2 en copia impresa . . 418

Visualización de la ayuda para estados de SQL

desde el procesador de línea de mandatos . . . . 419

Acceso a diferentes versiones del Centro de

información de DB2 . . . . . . . . . . . 420

Visualización de temas en el idioma preferido en el

Centro de información de DB2 . . . . . . . 420

Actualización del Centro de información de DB2

instalado en el sistema o en un servidor de intranet 421

Guías de aprendizaje de DB2 . . . . . . . . 423

Información de resolución de problemas de DB2 423

Términos y condiciones . . . . . . . . . . 424

Apéndice C. Avisos . . . . . . . . . 425

Marcas registradas . . . . . . . . . . . . 427

Índice . . . . . . . . . . . . . . . 429

Cómo ponerse en contacto con IBM 443

Contenido v

vi Desarrollo de aplicaciones de SQL incorporado

Parte 1. Desarrollo de aplicaciones cliente de SQL

incorporado

© Copyright IBM Corp. 1993, 2006 1

2 Desarrollo de aplicaciones de SQL incorporado

Capítulo 1. Introducción a SQL incorporado

Introducción a SQL incorporado . . . . . . . . 3

Incorporación de sentencias de SQL en un lenguaje

principal . . . . . . . . . . . . . . . . 4

Incorporación de sentencias de SQL en un

lenguaje principal . . . . . . . . . . . . 4

Sentencias de SQL incorporado en aplicaciones C

y C++ . . . . . . . . . . . . . . . 5


COBOL . . . . . . . . . . . . . . . 7


FORTRAN . . . . . . . . . . . . . . 8


REXX . . . . . . . . . . . . . . . . 9

Software de desarrollo soportado para aplicaciones


Configuración del entorno de desarrollo de SQL

incorporado . . . . . . . . . . . . . . 12

Introducción a SQL incorporado

Las aplicaciones de bases de datos de SQL incorporado se conectan a bases de

datos y ejecutan sentencias de SQL incorporado. Las sentencias de SQL

incorporado se incorporan dentro de una aplicación de lenguaje principal. Las

aplicaciones de bases de datos de SQL incorporado dan soporte a la incorporación

de sentencias de SQL que se tienen que ejecutar estática o dinámicamente.

Puede desarrollar aplicaciones de SQL incorporado para DB2 en los siguientes

lenguajes de programación principales: C, C++, COBOL, FORTRAN y REXX.

Nota: El soporte de SQL incorporado en FORTRAN y REXX ha quedado obsoleto

y permanecerá a nivel de DB2 Universal Database , Versión 5.2.

La creación de aplicaciones de SQL incorporado incluye dos pasos previos a la

compilación y enlace de la aplicación.

v Preparación de los archivos fuentes que contienen sentencias de SQL

incorporado mediante el precompilador de DB2.

El mandato PREP (PRECOMPILE) sirve para invocar el precompilador de DB2, que

lee el código fuente, lo analiza y convierte las sentencias de SQL incorporado en

llamadas a las API de servicios de tiempo de ejecución de DB2, y finalmente

escribe la salida en un nuevo archivo fuente modificado. El precompilador

genera planes de acceso para las sentencias de SQL que se almacenan juntas

como un paquete dentro de la base de datos.

v Vinculación de las sentencias de la aplicación con la base de datos de destino.

La vinculación se realiza por omisión durante la precompilación (el mandato

PREP). Si la vinculación se tiene que diferir (por ejemplo, el mandato BIND se

tiene que ejecutar más tarde), se tiene que especificar la opción BINDFILE en el

momento de especificar PREP para que se genere un archivo de vinculación.

Cuando haya precompilado y vinculado la aplicación de SQL incorporado, ya está

lista para que se compile y se enlace mediante las herramientas de desarrollo

específicas del lenguaje principal.

Para ayudar en el desarrollo de aplicaciones de SQL incorporado, puede consultar

la plantilla de SQL incorporado en C. En el directorio %DB2PATH%\SQLLIB\samples,

también se pueden encontrar ejemplos de aplicaciones de ejemplo de SQL

incorporado que funcionan.

Nota: %DB2PATH% es el directorio de instalación de DB2


SQL estático y dinámico:

Las sentencias de SQL se pueden ejecutar de dos formas: estática y dinámicamente.

Sentencias de SQL ejecutadas estáticamente

Para las sentencias de SQL ejecutadas estáticamente, la sintaxis se conoce

por completo en el momento de la precompilación. La estructura de una

sentencia de SQL se debe especificar por completo para que una sentencia

se considere estática. Por ejemplo, los nombres de las columnas y tablas a

las que se hace referencia en una sentencia se deben conocer por completo

en el momento de la precompilación. La única información que se puede

especificar en el tiempo de ejecución son los valores de las variables del

lenguaje principal a las que hace referencia la sentencia. Sin embargo, la

información sobre variables del lenguaje principal, como por ejemplo, tipos

de datos, debe estar ya precompilada. Debe precompilar, vincular y

compilar las sentencias de SQL ejecutadas estáticamente antes de ejecutar

la aplicación. El SQL estático se utiliza mejor en bases de datos cuyas

estadísticas no cambian mucho.

Sentencias de SQL ejecutadas dinámicamente

La aplicación crea y ejecuta las sentencias de SQL ejecutadas

dinámicamente en el momento de la ejecución. Una aplicación interactiva

que solicita al usuario final partes clave de una sentencia de SQL, como los

nombres de las tablas y las columnas que hay que buscar, es un buen

ejemplo de una situación adecuada para SQL dinámico.

Conceptos relacionados:

v “Sentencias de SQL incorporado en aplicaciones REXX” en la página 9

v “Sentencias de SQL incorporado en aplicaciones C y C++” en la página 5

v “Sentencias de SQL incorporado en aplicaciones COBOL” en la página 7

v “Sentencias de SQL incorporado en aplicaciones FORTRAN” en la página 8

Información relacionada:

v “Mandato PRECOMPILE” en Consulta de mandatos

Incorporación de sentencias de SQL en un lenguaje principal

Incorporación de sentencias de SQL en un lenguaje principal

Structured Query Language (SQL) es un lenguaje estandarizado que se puede

utilizar para manipular objetos de bases de datos y los datos que contienen. A

pesar de las diferencias entre los lenguajes principales, todas las aplicaciones de

SQL incorporado están formadas por tres elementos necesarios para configurar y

ejecutar una sentencia de SQL:

1. Una DECLARE SECTION para declarar variables del lenguaje principal. No es

necesario que la declaración de la estructura SQLCA esté en la sección

DECLARE.

2. El cuerpo principal de la aplicación, la configuración y ejecución de sentencias

de SQL.

3. Colocaciones de lógica que confirma o retrotrae los cambios realizados por las

sentencias de SQL.


Para cada lenguaje principal, hay ciertas diferencias entre las directrices generales

que se aplican a todos los lenguajes y las reglas específicas de los lenguajes

individuales.






Sentencias de SQL incorporado en aplicaciones C y C++

Las aplicaciones C y C++ de SQL incorporado constan de tres elementos

principales para configurar y ejecutar una sentencia de SQL.

v Una DECLARE SECTION para declarar variables del lenguaje principal. La

declaración de la estructura SQLCA no necesita estar en la sección DECLARE.

v El cuerpo principal de la aplicación, la configuración y ejecución de sentencias

de SQL

v Colocaciones de lógica que confirman o retrotraen los cambios realizados por las

sentencias de SQL

Sintaxis correcta de elementos de C y C++

Inicializador de la sentencia EXEC SQL

Serie de la sentencia Cualquier sentencia de SQL válida

Terminador de la sentencia Punto y coma (;)

Por ejemplo, para ejecutar una sentencia de SQL estáticamente dentro de una

aplicación C, podría incluir lo siguiente dentro del código de la aplicación:

EXEC SQL SELECT col INTO :hostvar FROM table;

El ejemplo siguiente muestra cómo ejecutar una sentencia de SQL dinámicamente

utilizando la variable del lenguaje principal stmt1:

strcpy(stmt1, "CREATE TABLE table1(col1 INTEGER)");

EXEC SQL EXECUTE IMMEDIATE :stmt1;

Las siguientes directrices y reglas se aplican a la ejecución de sentencias de SQL

incorporado en aplicaciones C y C++:

v Puede empezar la serie de la sentencia de SQL en la misma línea que el

inicializador de sentencia EXEC SQL.

v No divida EXEC SQL en distintas líneas.

v Debe utilizar el terminador de sentencias de SQL. De no utilizarlo, el

precompilador seguirá hasta el siguiente terminador de la aplicación. Esto puede

producir errores indeterminados.

v Se pueden colocar comentarios de C y C++ delante del inicializador de la

sentencia o detrás del terminador de la sentencia.

v Se pueden poner varias sentencias de SQL y de C o C++ en la misma línea. Por

ejemplo:

EXEC SQL OPEN c1; if (SQLCODE >= 0) EXEC SQL FETCH c1 INTO :hv;

v Los retornos de carro, saltos de línea y tabulaciones se pueden incluir dentro de

una serie entrecomillada. El precompilador de SQL los dejará tal cual.

Capítulo 1. Introducción a SQL incorporado 5

v No utilice la sentencia #include para incluir archivos que contengan sentencias

de SQL. Las sentencias de SQL se precompilan antes de que se compile el

módulo. El precompilador pasará por alto la sentencia #include. En su lugar,

utilice la sentencia INCLUDE de SQL para importar los archivos include.

v Están permitidos los comentarios de SQL en cualquier línea que forme parte de

una sentencia de SQL incorporado, con a excepción de las sentencias ejecutadas

dinámicamente.

– El formato de un comentario de SQL consiste en un guión doble (--), seguido

de una serie compuesta por cero o más caracteres y terminada por un fin de

línea.

– No coloque comentarios de SQL detrás del terminador de la sentencia de

SQL. Estos comentarios de SQL provocan errores de compilación ya que los

compiladores los interpretan como sintaxis de C o C++.

– Puede utilizar comentarios de SQL en una serie de una sentencia estática

siempre que se permitan caracteres en blanco.

– El uso de los delimitadores de comentarios de C y C++ /* */ está permitido

en las sentencias de SQL incorporado tanto estáticas como dinámicas.

– La utilización de comentarios de C++ de estilo // no están permitidos dentro

de sentencias de SQL estáticov Los literales de la serie de SQL y los identificadores delimitados se pueden

continuar con divisiones de línea en las aplicaciones C y C++. Para ello, utilice

una barra inclinada invertida (\) al final de la línea en que desea que se

produzca la división. Por ejemplo, para seleccionar datos de la columna NAME

de la tabla staff donde la columna NAME sea igual a ’Sanders’, podría hacer

algo parecido a lo siguiente:

EXEC SQL SELECT "NA\

ME" INTO :n FROM staff WHERE name=’Sa\

nders’;

Los caracteres de línea nueva (como, por ejemplo, el retorno de carro y el salto

de línea) no se incluyen en la serie que se pasa al gestor de base de datos como

sentencia de SQL.

v La sustitución de caracteres de espacio en blanco, como caracteres de fin de línea

y de tabulación, se produce del siguiente modo:

– Cuando aparecen fuera de las comillas (pero dentro de sentencias de SQL),

los caracteres de fin de línea y tabuladores se sustituyen por un solo espacio.

– Si aparecen dentro de las comillas, los caracteres de fin de línea desaparecen,

siempre que se continúe correctamente la serie para un programa C. Los

tabuladores no se modifican.

Observe que los caracteres reales utilizados para el final de línea y el tabulador

varían según la plataforma. Por ejemplo, los sistemas basados en UNIX y Linux

utilizan un carácter de salto de línea.


v “Comentarios en aplicaciones de SQL incorporado” en la página 150

v “Sentencias dinámicas de SQL incorporado” en la página 21


v “Sentencias de SQL soportadas” en Desarrollo de SQL y rutinas externas


Sentencias de SQL incorporado en aplicaciones COBOL

Las sentencias de SQL incorporado en aplicaciones COBOL constan de estos tres

elementos:

Elemento Sintaxis correcta en COBOL


Serie de la sentencia Cualquier sentencia de SQL válida

Terminador de la sentencia END-EXEC.

Por ejemplo:

EXEC SQL SELECT col INTO :hostvar FROM table END-EXEC.

Se aplican las reglas siguientes a las sentencias de SQL incorporado en aplicaciones

COBOL:

v Las sentencias de SQL ejecutables se deben colocar en la sección PROCEDURE

DIVISION. Las sentencias de SQL pueden ir precedidas de un nombre de párrafo,

al igual que una sentencia de COBOL.

v Las sentencias de SQL puede empezar en el Área A (columnas 8 a 11) o en el

Área B (columnas 12 a 72).

v Inicie cada sentencia de SQL con el inicializador de sentencia EXEC SQL y

termínela con el terminador de sentencia END-EXEC. El precompilador SQL

incluye cada una de las sentencias de SQL como comentarios en el archivo

fuente modificado.

v Debe utilizar el terminador de sentencias de SQL. De no utilizarlo, el

precompilador seguirá hasta el siguiente terminador de la aplicación. Esto puede

producir errores indeterminados.


una sentencia de SQL incorporado. Estos comentarios no están permitidos en las

sentencias que se ejecutan de forma dinámica. El formato de un comentario de

SQL consiste en un guión doble (--), seguido de una serie compuesta por cero o

más caracteres y terminada por un fin de línea. No coloque comentarios de SQL

detrás del terminador de la sentencia de SQL, puesto que ocasionarían errores

de compilación debido a que parecería que forman parte del lenguaje COBOL.

v Se permiten comentarios de COBOL en casi todas partes. Las excepciones son:

– No se permiten comentarios entre EXEC y SQL.

– No se permiten comentarios en las sentencias que se ejecutan dinámicamente.v Las sentencias de SQL siguen las mismas normas de continuación de línea que el

lenguaje COBOL. No obstante, no divida el inicializador de sentencia EXEC SQL

en distintas líneas.

v No utilice la sentencia COPY de COBOL para incluir archivos que contengan

sentencias de SQL. Las sentencias de SQL se precompilan antes de que se

compile el módulo. El precompilador pasará por alto la sentencia COPY de

COBOL. En su lugar, utilice la sentencia INCLUDE de SQL para importar los

archivos include.

v Para continuar una constante de serie en la línea siguiente, en la columna 7 de la

línea de continuación debe aparecer un '-' y en la columna 12 o posteriores debe

aparecer un delimitador de serie.

v Los operadores aritméticos de SQL se deben delimitar mediante espacios en

blanco.







siempre que se continúe correctamente la serie para un programa COBOL.

Los tabuladores no se modifican.

Observe que los caracteres reales utilizados como fin de línea y tabulador varían

en función de la plataforma. Por ejemplo, las plataformas basadas en Windows

utilizan el retorno de carro/salto de línea como fin de línea, mientras que los

sistemas basados en UNIX y Linux utilizan simplemente un salto de línea.



v “Restricciones en el uso de COBOL para programar aplicaciones de SQL

incorporado” en la página 28



v “Sentencia INCLUDE” en Consulta de SQL, Volumen 2

v “Archivos include para aplicaciones de SQL incorporado COBOL” en la página

50

Sentencias de SQL incorporado en aplicaciones FORTRAN

Las sentencias de SQL incorporado en aplicaciones FORTRAN constan de estos tres

elementos:

Elemento Sintaxis correcta en FORTRAN


Serie de la sentencia Cualquier sentencia de SQL válida con blancos

como delimitadores

Terminador de la sentencia Fin de la línea fuente.

El fin de la línea fuente sirve como terminador de sentencia. Si se continúa la línea,

el terminador de sentencia es el fin de la última línea de continuación.

Por ejemplo:

EXEC SQL SELECT COL INTO :hostvar FROM TABLE

Se aplican las reglas siguientes a las sentencias de SQL incorporado en aplicaciones

FORTRAN:

v Codifique las sentencias de SQL únicamente entre las columnas 7 y 72.

v Utilice comentarios de FORTRAN de línea completa, o comentarios de SQL, pero

no utilice el carácter '!' de comentario de fin de línea de FORTRAN en las

sentencias de SQL. Este carácter de comentario se puede utilizar en cualquier

otra parte, incluso en las declaraciones de variables del lenguaje principal.

v Utilice blancos como delimitadores cuando codifique sentencias de SQL

incorporado, aunque las sentencias de FORTRAN no requieren blancos como

delimitadores.

v Utilice únicamente una sentencia de SQL para cada línea fuente en FORTRAN.

Para las sentencias que necesitan más de una línea fuente, se aplican las normas

habituales de continuación de FORTRAN. No divida el inicializador de sentencia

EXEC SQL en distintas líneas.



una sentencia de SQL incorporado. Estos comentarios no están permitidos en las

sentencias que se ejecutan de forma dinámica. El formato de un comentario de

SQL consiste en un guión doble (--) seguido de una serie compuesta por cero o

más caracteres y terminada por un fin de línea.

v Los comentarios FORTRAN están permitidos casi en cualquier lugar de una

sentencia de SQL incorporada. Las excepciones son:

– No se permiten comentarios entre EXEC y SQL.

– No se permiten comentarios en las sentencias que se ejecutan dinámicamente.

– La ampliación de utilizar ! para codificar un comentario FORTRAN al final

de una línea no recibe soporte dentro de una sentencia de SQL incorporado.v Utilice una notación exponencial cuando especifique una constante real en las

sentencias de SQL. El gestor de bases de datos interpreta una serie de dígitos

con una coma decimal en una sentencia de SQL como una constante decimal, no

como una constante real.

v Los números de sentencia no son válidos en las sentencias de SQL que preceden

a la primera sentencia FORTRAN ejecutable. Si una sentencia de SQL tiene

asociado un número de sentencia, el precompilador genera una sentencia

CONTINUE etiquetada que precede directamente a la sentencia de SQL.

v Cuando haga referencia a variables del lenguaje principal dentro de una

sentencia de SQL, utilícelas exactamente tal como se han declarado.






siempre que se continúe correctamente la serie para un programa FORTRAN.

Los tabuladores no se modifican.

Observe que los caracteres reales utilizados como fin de línea y tabulador varían

en función de la plataforma. Por ejemplo, las plataformas basadas en Windows

utilizan el retorno de carro/salto de línea como fin de línea, mientras que las

plataformas basadas en UNIX y Linux sólo utilizan simplemente un salto de

línea.



v “Transacciones simultáneas y acceso a base de datos de varias hebras en

aplicaciones de SQL incorporado” en la página 31

v “Nombres de variables del lenguaje principal en aplicaciones de SQL

incorporado FORTRAN” en la página 133

v “Restricciones en el uso de FORTRAN para programar aplicaciones de SQL




Sentencias de SQL incorporado en aplicaciones REXX

Las aplicaciones REXX utilizan API que les permiten utilizar la mayoría de las

funciones que suministran las API del gestor de bases de datos y SQL. A diferencia

de las aplicaciones escritas en un lenguaje compilado, las aplicaciones REXX no se

precompilan. En su lugar, un manejador de SQL dinámico procesa todas las


sentencias de SQL. Al combinar REXX con estas API que se pueden llamar, tiene

acceso a la mayoría de las funciones del gestor de bases de datos. Aunque REXX

no da soporte directamente a algunas API utilizando SQL incorporado, se puede

acceder a las mismas utilizando el procesador de línea de mandatos de DB2 desde

dentro de la aplicación REXX.

Como REXX es un lenguaje interpretado, resultará más fácil desarrollar y depurar

los prototipos de aplicación en REXX que en lenguajes principales compilados.

Aunque las aplicaciones de bases de datos codificadas en REXX no proporcionan el

rendimiento de las aplicaciones de bases de datos que utilizan lenguajes

compilados, proporcional la posibilidad de crear aplicaciones de bases de datos sin

tener que precompilar, compilar, enlazar o utilizar software adicional.

Utilice la rutina SQLEXEC para procesar todas las sentencias de SQL. Los

argumentos de serie de caracteres para la rutina SQLEXEC están formados por los

elementos siguientes:

v Palabras clave de SQL

v Identificadores declarados previamente

v Variables del lenguaje principal de sentencia

Realice cada petición pasando una sentencia de SQL válida a la rutina SQLEXEC.

Utilice la sintaxis siguiente:

CALL SQLEXEC 'sentencia'

Las sentencias de SQL se pueden continuar en más de una línea. Cada parte de la

sentencia se debe encerrar entre comillas, y se debe delimitar mediante una coma

el texto adicional de la sentencia, del modo siguiente:

CALL SQLEXEC 'SQL text',

'additional text',

.

.

.

'final text'

A continuación se muestra un ejemplo de incorporación de una sentencia de SQL

en REXX:

statement = "UPDATE STAFF SET JOB = ’Clerk’ WHERE JOB = ’Mgr’"

CALL SQLEXEC ’EXECUTE IMMEDIATE :statement’

IF ( SQLCA.SQLCODE < 0) THEN

SAY ’Update Error: SQLCODE = ’ SQLCA.SQLCODE

En este ejemplo, el campo SQLCODE de la estructura SQLCA se comprueba para

determinar si la actualización ha resultado satisfactoria.

Se aplican las normas siguientes a las sentencias de SQL incorporado: en

aplicaciones REXX

v Las sentencias de SQL siguientes se pueden pasar directamente a la rutina

SQLEXEC:

– CALL

– CLOSE

– COMMIT

– CONNECT

– CONNECT TO

– CONNECT RESET

– DECLARE

– DESCRIBE

– DISCONNECT


– EXECUTE

– EXECUTE IMMEDIATE

– FETCH

– FREE LOCATOR

– OPEN

– PREPARE

– RELEASE

– ROLLBACK

– SET CONNECTION

Existen otras sentencias de SQL que se deben procesar dinámicamente utilizando

las sentencias EXECUTE IMMEDIATE o PREPARE y EXECUTE junto con la

rutina SQLEXEC.

v No se pueden utilizar variables del lenguaje principal en las sentencias

CONNECT y SET CONNECTION en REXX.

v Los nombres de cursor y los nombres de sentencia están predefinidos del modo

siguiente:

de c1 a c100

Nombres de cursor, que van de c1 a c50 para los cursores declarados sin

la opción WITH HOLD, y de c51 a c100 para los cursores declarados

utilizando la opción WITH HOLD.

El identificador de nombre de cursor se utiliza para las sentencias

DECLARE, OPEN, FETCH y CLOSE. Identifica el cursor utilizado en la

petición de SQL.

de s1 a s100

Nombres de sentencia, que van de s1 a s100.

El identificador de nombre de sentencia se utiliza con las sentencias

DECLARE, DESCRIBE, PREPARE y EXECUTE.Se deben utilizar identificadores declarados previamente para los nombres de

cursor y de sentencia. No se admiten otros nombres.

v Cuando se declaren cursores, el nombre de cursor y el nombre de sentencia

deben corresponder en la sentencia DECLARE. Por ejemplo, si se utiliza c1 como

nombre de cursor, se debe utilizar s1 como nombre de sentencia.

v No utilice comentarios dentro de una sentencia de SQL.

Nota: REXX no da soporte al acceso a bases de datos de varias hebras.


v “Sintaxis de las API para REXX” en la página 173



v “Restricciones en el uso de REXX para programar aplicaciones de SQL



v “Ejemplos de REXX” en la página 412


Software de desarrollo soportado para aplicaciones de SQL

incorporado

Los sistemas de bases de datos DB2 dan soporte a compiladores, intérpretes y

software de desarrollo relacionado para aplicaciones de SQL incorporado en los

siguientes sistemas operativos:

v AIX

v HP-UX

v Linux

v Solaris

v Windows

Las aplicaciones de SQL incorporado de 32 y de 64 bits se pueden crear a partir de

código fuente de SQL incorporado.

Los siguientes lenguajes principales requieren compiladores específicos para

desarrollar aplicaciones de SQL incorporado:

v C

v C++

v COBOL

v Fortran

v REXX


v “Soporte de 32 bits y 64 bits para aplicaciones de SQL incorporado” en la página

26

v “Restricciones en el uso de COBOL para programar aplicaciones de SQL


v “Restricciones en el uso de FORTRAN para programar aplicaciones de SQL


Configuración del entorno de desarrollo de SQL incorporado

Para poder empezar a crear aplicaciones de SQL incorporado, tiene que instalar el

compilador soportado para el lenguaje principal que va a utilizar para desarrollar

las aplicaciones y configurar el entorno de SQL incorporado.

Requisitos previos:

v Servidor de bases de datos DB2 instalado en una plataforma soportada

v Cliente DB2 instalado

v Software de desarrollo de aplicaciones de SQL incorporado soportado instalado

Procedimiento:

Asigne al usuario la autorización para emitir el mandato PREP y el mandato

BIND.


Para verificar que el entorno de desarrollo de aplicaciones de SQL incorporado está

correctamente configurado, intente crear y ejecutar la plantilla de aplicación de

SQL incorporado que encontrará en el tema: Plantilla de aplicación de SQL

incorporado en C.


v “Plantilla de aplicación de SQL incorporado en C” en la página 44

v “Creación de aplicaciones de SQL incorporado mediante el script de creación de

ejemplo” en la página 221

v “Creación de aplicaciones de SQL incorporado” en la página 198

v “Creación de aplicaciones de SQL incorporado desde la línea de mandatos” en la

página 268

v “Precompilación de aplicaciones de SQL incorporado con el mandato

PRECOMPILE” en la página 201

v “Consideraciones sobre la vinculación” en la página 216


v “Soporte para elementos del entorno de desarrollo de aplicaciones de bases de

datos” en Iniciación al desarrollo de aplicaciones de bases de datos

v “Sentencia GRANT (Privilegios de paquete)” en Consulta de SQL, Volumen 2


Capítulo 2. Diseño de aplicaciones de SQL incorporado

Diseño de aplicaciones de SQL incorporado . . . 15

Uso de SQL estático . . . . . . . . . . . 16

Uso de SQL dinámico . . . . . . . . . . . 18

Consideraciones sobre autorización para SQL

incorporado . . . . . . . . . . . . . . 19

Ejecución de sentencias de SQL estático y dinámico

en aplicaciones de SQL incorporado . . . . . . 20

Ejecución de sentencias de SQL estático y

dinámico en aplicaciones de SQL incorporado . . 20

Sentencias dinámicas de SQL incorporado . . . 21

Determinación del momento en que deben

ejecutarse sentencias de SQL estática o

dinámicamente en aplicaciones de SQL

incorporado . . . . . . . . . . . . . 22

Rendimiento de aplicaciones de SQL incorporado . 25

Soporte de 32 bits y 64 bits para aplicaciones de

SQL incorporado . . . . . . . . . . . . 26

Restricciones en aplicaciones SQL incorporadas . . 27

Restricciones sobre juegos de caracteres cuando

se utiliza C y C++ para programar aplicaciones


Restricciones en el uso de COBOL para


Restricciones en el uso de FORTRAN para


Restricciones en el uso de REXX para programar


Recomendaciones para desarrollar aplicaciones

de SQL incorporado con XML y XQuery . . . . 30

Transacciones simultáneas y acceso a base de datos

de varias hebras en aplicaciones de SQL

incorporado . . . . . . . . . . . . . . 31

Transacciones simultáneas y acceso a base de

datos de varias hebras en aplicaciones de SQL

incorporado . . . . . . . . . . . . . 31

Recomendaciones para utilizar varias hebras . . 34

Consideraciones sobre la página de códigos y el

código de país o región para aplicaciones UNIX

de varias hebras . . . . . . . . . . . . 35

Resolución de problemas de aplicaciones de SQL

incorporado de varias hebras . . . . . . . 36

Diseño de aplicaciones de SQL incorporado

Cuando se diseñan aplicaciones de SQL incorporado, se tienen que utilizar

sentencias de SQL ejecutadas estática o dinámicamente. Las sentencias de SQL

estático son de dos tipos: sentencias que no contienen variables del lenguaje

principal (utilizadas principalmente para inicialización y ejemplos de SQL

sencillos) y sentencias que utilizan variables del lenguaje principal. Las sentencias

de SQL dinámico también son de dos tipos: pueden no contener ningún marcador

de parámetro (típico de interfaces como CLP) o pueden contener marcadores de

parámetro, lo que ofrece mayor flexibilidad dentro de las aplicaciones.

La opción sobre si utilizar sentencias ejecutadas estática o dinámicamente depende

de varios factores que incluyen portabilidad, rendimiento y restricciones de las

aplicaciones de SQL incorporado.


v “Soporte de 32 bits y 64 bits para aplicaciones de SQL incorporado” en la página

26



v “Rendimiento de aplicaciones de SQL incorporado” en la página 25

v “Ejecución de sentencias de SQL estático y dinámico en aplicaciones de SQL



Uso de SQL estático

SQL estático suele utilizarse en aplicaciones de bases de datos de SQL incorporado.

Las sentencias de SQL estático se codifican en un programa de aplicación de SQL

incorporado cuando se escribe el código fuente. El gestor de bases de datos DB2

debe procesar el código fuente utilizando un precompilador de SQL antes de que

se pueda compilar y ejecutar. Durante este proceso, el precompilador de SQL

evalúa referencias a tablas, columnas y tipos de datos declarados de todas las

variables del lenguaje principal y determina qué métodos de conversión de datos

se tienen que utilizar cuando los datos se muevan de la base de datos y a la

misma. Además, el precompilador de SQL realiza una comprobación de errores de

cada sentencia de SQL codificada y asegura que se utilizan los tipos de datos de

variables del lenguaje principal adecuados para sus respectivos valores de

columnas de la tabla. SQL estático se denomina estático porque las sentencias de

SQL del programa no cambian cada vez que se ejecuta el programa. SQL estático

funciona bien en muchas situaciones. De hecho, se puede utilizar en cualquier

aplicación para la que el acceso a los datos se pueda determinar en el momento de

diseñar el programa. Por ejemplo, un programa de entrada de pedidos siempre

utiliza la misma sentencia para insertar un nuevo pedido, y un sistema de reserva

de vuelos siempre utiliza la misma sentencia para cambiar el estado de una plaza

de ’disponible’ a ’reservada’. Cada una de estas sentencias se generalizaría

mediante el uso de variables del lenguaje principal. Se pueden insertar distintos

valores en un pedido de compras y se pueden reservar diferentes plazas. Puesto

que estas sentencias se pueden codificar en el programa, estos programas tienen la

ventaja de que las sentencias se tienen que analizar, validar y optimizar una sola

vez, en el momento de la compilación. Esto da lugar a un código relativamente

rápido en el momento de la ejecución.

Aunque las sentencias de SQL estático son fáciles de utilizar, están limitadas

porque el precompilador debe conocer por anticipado su formato y porque sólo

funcionan con variables del lenguaje principal. Hay muchas situaciones en las que

el programador no conoce por anticipado el contenido de una sentencia de SQL.

Por ejemplo, supongamos que una hoja de cálculo permite a un usuario entrar una

consulta, que la hoja de cálculo envía al sistema de gestión de bases de datos para

recuperar datos. Obviamente, el programador no sabe el contenido de esta consulta

cuando se escribe el programa de la hoja de cálculo.

A continuación se proporcionan detalles sobre la función SQL estático:

Interfaces que dan soporte a la ejecución de SQL estático::

SQL estático se puede ejecutar desde las siguientes interfaces:

v Aplicaciones de SQL incorporado

v Rutinas de SQL incorporado

v Aplicaciones de SQLJ

v Rutinas de SQLJ

v Rutinas de SQL

Implementación fácil de programar:

En general, la programación que utiliza SQL estático es más sencilla que la que

utiliza SQL dinámico incorporado. Las sentencias de SQL estático simplemente se

incorporan en el archivo fuente del lenguaje principal, y el precompilador maneja

la conversión necesaria a las llamadas a API de servicio de tiempo de ejecución del


gestor de bases de datos que puede procesar el compilador del lenguaje principal.

Dentro de los programas de SQL incorporado, hay dos implementaciones

principales de SQL estático:

v SQL estático que no contiene variables del lenguaje principal

– Este tipo de implementación suele ser rara y se utiliza principalmente para el

código de inicialización y en ejemplos sencillos de SQL. SQL estático sin

variables del lenguaje principal funciona muy bien, porque no hay variables

del lenguaje principal que resolver, no hay sobrecarga del rendimiento en el

momento de la ejecución y se puede aprovechar por completo la capacidad

del optimizador de DB2.v SQL estático que contiene variables del lenguaje principal

– Es un estilo antiguo tradicional de SQL estático. Aunque SQL estático con

variables del lenguaje principal funciona mejor en el momento de la ejecución

que SQL dinámico, que necesita preparación de sentencias y el

establecimiento de bloqueos del catálogo durante la compilación de

sentencias, no se puede utilizar la potencia completa del optimizador porque

este no conoce la sentencia de SQL completa. Esto puede resultar un

problema cuando los datos con los que trabaja una sentencia de SQL tienen

una distribución de datos poco uniforme. Por este motivo, SQL estático sin

variables del lenguaje principal puede funcionar mejor. Por supuesto, las

variables del lenguaje principal proporcionan soporte para vincular valores de

variables con una sentencia.

Rendimiento:

En general, la ejecución de una consulta como SQL estático asegura un buen

rendimiento de la consulta. Ambas formas de sentencias de SQL estático descritas

anteriormente se pueden utilizar para conseguir un mejor rendimiento del que

permite la utilización de SQL dinámico. Para programas de SQL sencillos de corta

ejecución, una sentencia de SQL estático se ejecuta más rápido que la misma

sentencia procesada de forma dinámica porque el proceso general de preparación

de un formato ejecutable de la sentencia se realiza en el momento de la

precompilación en lugar de en el tiempo de ejecución.

El rendimiento de SQL estático depende de las estadísticas de la base de datos la

última vez que se vinculó la aplicación. Sin embargo, si estas estadísticas cambian,

el rendimiento de SQL dinámico equivalente puede ser muy diferente. Si, por

ejemplo, se añade un índice a una base de datos posteriormente, una aplicación

que utilice SQL estático no puede aprovechar el índice a no ser que se vuelva a

vincular a la base de datos. Además, si utiliza variables del lenguaje principal en

una sentencia de SQL estático, el optimizador no podrá aprovechar la información

sobre distribución de datos.

Autorización:

La autorización de la persona que vincula un paquete de aplicación se utiliza en el

momento de la ejecución para validar los privilegios necesarios para ejecutar las

sentencias de SQL estático utilizadas en la aplicación. Esto significa que el usuario

final que ejecuta la aplicación no necesita directamente los privilegios para ejecutar

las sentencias individuales del paquete. Por ejemplo, supongamos que tenemos

una aplicación que contiene sentencias de SQL que actualizan una tabla que

almacena datos de inventario. Una vez que alguien con los privilegios necesarios

para actualizar la tabla vincula la base de datos, los demás usuarios podrán

ejecutar ya aplicación y realizar actualizaciones de la tabla de inventario.

Capítulo 2. Diseño de aplicaciones de SQL incorporado 17

La combinación de funciones de SQL estático lo convierten en la opción adecuada

para aplicaciones en las que la sintaxis de las sentencias de SQL se conoce en el

momento de programar la aplicación y en los casos en los que el rendimiento de

las sentencias de SQL resulta crucial para el rendimiento de la aplicación. También

puede facilitar el mantenimiento del código de programación de aplicaciones y

simplificar la gestión de autorizaciones necesarias para ejecutar SQL dentro de

aplicaciones.

Uso de SQL dinámico

SQL dinámico se suele utilizar para enviar sentencias de SQL al gestor de bases de

datos desde interfaces de usuario gráficas e interactivas de creación de consultas y

procesadores de línea de mandatos de SQL, así como desde aplicaciones en las que

la estructura completa de consultas no se conoce en el momento de compilar la

aplicación y la API de programación da soporte a SQL dinámico.

Hay muchas situaciones en las que un usuario o un programador no conoce por

anticipado el contenido de una sentencia de SQL. Por ejemplo, supongamos que

una hoja de cálculo permite a un usuario entrar una consulta, que la hoja de

cálculo envía al sistema de gestión de bases de datos para recuperar datos.

Obviamente, el programador no sabe el contenido de esta consulta cuando se

escribe el programa de la hoja de cálculo. Para resolver el problema, la hoja de

cálculo utiliza una forma de SQL incorporado denominada SQL dinámico. A

diferencia de las sentencias de SQL estático, que están codificadas en el programa,

las sentencias de SQL dinámico se pueden crear en el momento de la ejecución y

colocar en una variable del lenguaje principal de tipo serie (string). Luego se

envían al sistema de gestión de bases de datos para que las procese. Puesto que el

sistema de gestión de bases de datos debe generar un plan de acceso en el

momento de la ejecución para las sentencias de SQL dinámico, este suele ser más

lento que SQL estático. Cuando se compila un programa que contiene sentencias

de SQL dinámico, estas sentencias no se eliminan del programa, como en SQL

estático. En su lugar, se sustituyen por una llamada de función que pasa la

sentencia al DBMS.

Puesto que la creación real de sentencias de SQL dinámico se basa en el flujo de

lógica de programación en el momento de la ejecución de la aplicación, son más

potentes que las sentencias de SQL estático. Sin embargo, puesto que el DBMS

debe pasar por cada uno de los diversos pasos del proceso de una sentencia de

SQL para cada petición dinámica, SQL dinámico tiende a ser más lento que SQL

estático. El gestor de bases de datos DB2 proporciona soporte interno para una

antememoria de sentencias dinámicas, que ayudará a mejorar automáticamente el

rendimiento de las consultas de SQL dinámico.

SQL dinámico se puede utilizar desde las siguientes interfaces:

v Aplicaciones y rutinas externas que utilizan API que dan soporte a SQL

dinámico, que incluyen: SQL incorporado, JDBC, CLI, ADO.NET

v Interfaces interactivas de GUI de DB2 que incluyen: editor de mandatos de DB2

del Centro de control de DB2

v Procesador de línea de mandatos de DB2

v Ventana de mandatos de DB2


Consideraciones sobre autorización para SQL incorporado

Una autorización permite a un usuario o grupo llevar a cabo una tarea general

como conectarse a una base de datos, crear tablas o administrar un sistema. Un

privilegio otorga a un usuario o grupo el derecho a acceder a un objeto de base de

datos específico de una forma especificada. DB2® utiliza un grupo de privilegios

para proteger la información que almacena en el mismo.

La mayoría de las sentencias de SQL necesitan algún tipo de privilegio sobre los

objetos de base de datos que utiliza la sentencia. La mayoría de llamadas a API no

suelen necesitar ningún privilegio sobre los objetos de base de datos que utiliza la

llamada, aunque muchas API necesitan que el usuario tenga la autorización

necesaria para invocarlas. Las API de DB2 le permiten realizar funciones

administrativas de DB2 desde dentro del programa de aplicación. Por ejemplo,

para recrear un paquete almacenado en la base de datos sin necesidad de disponer

de un archivo de vinculación, puede utilizar la API sqlarbnd (o REBIND).

Los grupos proporcionan un medio conveniente para llevar a cabo la autorización

para un conjunto de usuarios sin tener que otorgar ni revocar privilegios

individualmente para cada usuario. La pertenencia a un grupo se tiene en cuenta

en la ejecución de sentencias de SQL dinámico, pero no en sentencias de SQL

estático. Sin embargo, los privilegios PUBLIC se tienen en cuenta en la ejecución de

sentencias de SQL estático. Por ejemplo, suponga que tiene un procedimiento

almacenado de SQL incorporado con consultas de SQL vinculadas estáticamente

sobre una tabla llamada STAFF. Si intenta crear este procedimiento con la sentencia

CREATE PROCEDURE y la cuenta pertenece a un grupo que tiene el privilegio de

selección para la tabla STAFF, la sentencia CREATE fallará con un error SQL0551N.

Para que la sentencia CREATE funcione, la cuenta necesita directamente el privilegio

de selección en la tabla STAFF.

Cuando diseñe la aplicación, tenga en cuenta los privilegios que necesitarán los

usuarios para ejecutar la aplicación. Los privilegios que necesitan los usuarios

dependen de:

v Si la aplicación utiliza SQL dinámico, incluidos JDBC y CLI de DB2, o SQL

estático. Para obtener información sobre los privilegios necesarios para emitir

una sentencia, consulte la descripción de dicha sentencia.

v Qué API utiliza la aplicación. Para obtener información sobre las autorizaciones

y los privilegios necesarios para una llamada a API, consulte la descripción de

dicha API.

Los grupos proporcionan un medio conveniente para llevar a cabo la autorización

para un conjunto de usuarios sin tener que otorgar ni revocar privilegios

individualmente para cada usuario. En general, la pertenencia a un grupo se tiene

en cuenta en sentencias de SQL dinámico, pero no se tiene en cuenta en sentencias

de SQL estático. La excepción a este caso general se da cuando se otorgan

privilegios a PUBLIC: estos privilegios se tienen en cuenta cuando se procesan

sentencias de SQL.

Supongamos que tenemos dos usuarios, PAYROLL y BUDGET, que tienen que

realizar consultas contra la tabla STAFF. PAYROLL es responsable de pagar a los

empleados de la empresa, de modo que tiene que emitir varias sentencias SELECT

al emitir cheques. PAYROLL tiene que poder acceder al salario de cada empleado.

BUDGET es responsable de determinar la cantidad de dinero necesaria para pagar

los salarios. Sin embargo, BUDGET no debería poder ver el salario de ningún

empleado en particular.


Puesto que PAYROLL emite muchas sentencias SELECT diferentes, la aplicación

que diseñe para PAYROLL probablemente podría utilizar de forma eficiente código

SQL dinámico. El código SQL dinámico necesitaría que PAYROLL tuviera el

privilegio SELECT sobre la tabla STAFF. Este requisito no representa un problema

porque PAYROLL necesita acceso completo a la tabla.

Por otro lado, BUDGET no debería tener acceso al salario de cada empleado. Esto

significa que no debe otorgar el privilegio SELECT sobre la tabla STAFF a

BUDGET. Puesto que BUDGET necesita acceso al total de todos los salarios de la

tabla STAFF, podría crear una aplicación de SQL estático para ejecutar una

sentencia SELECT SUM(SALARY) FROM STAFF, vincular la aplicación y otorgar el

privilegio EXECUTE sobre el paquete de la aplicación a BUDGET. Esto permite a

BUDGET obtener la información necesaria sin exponer la información que

BUDGET no debería ver.


v “Authorization” en Administration Guide: Planning

v “Consideraciones de autorización para SQL dinámico” en Desarrollo de SQL y

rutinas externas

v “Consideraciones de autorización para SQL estático” en Desarrollo de SQL y

rutinas externas

Ejecución de sentencias de SQL estático y dinámico en aplicaciones

de SQL incorporado

Ejecución de sentencias de SQL estático y dinámico en

aplicaciones de SQL incorporado

La ejecución tanto de sentencias de SQL estático y como de SQL dinámico recibe

soporte en aplicaciones de SQL incorporado. Para decidir si hay que ejecutar las

sentencias de SQL de forma estática o dinámica hay que comprender los paquetes,

cómo se ejecutan las sentencias de SQL en el momento de la ejecución, las

variables del lenguaje principal, los marcadores de parámetro y cómo estos

elementos se relacionan con el rendimiento de la aplicación.

SQL estático en programas de SQL incorporado:

A continuación se muestra un ejemplo de una sentencia ejecutada estáticamente en

C:

/* seleccionar valores de table a variables lenguaje principal */

/* con STATIC SQL e imprimirlos */

EXEC SQL SELECT id, name, dept, salary INTO :id, :name, :dept, :salary

FROM staff WHERE id = 310;

printf(" %3d %-8.8s %4d %7.2f\n\n", id, name, dept, salary);

SQL dinámico en programas de SQL incorporado:

A continuación se muestra un ejemplo de una sentencia ejecutada dinámicamente

en C:

/* Actualizar columna de tabla mediante DYNAMIC SQL*/

strcpy(hostVarStmtDyn, "UPDATE staff SET salary = salary + 1000 WHERE dept = ?");

EXEC SQL PREPARE StmtDyn FROM :hostVarStmtDyn;

EXEC SQL EXECUTE StmtDyn USING :dept;



v “Uso de SQL dinámico” en la página 18

v “Uso de SQL estático” en la página 16

v “Incorporación de sentencias de SQL en un lenguaje principal” en la página 4




Sentencias dinámicas de SQL incorporado

Las sentencias de SQL dinámico aceptan una variable del lenguaje principal de

serie de caracteres y un nombre de sentencia como argumentos. La variable del

lenguaje principal contiene la sentencia de SQL que se va a procesar de forma

dinámica en formato de texto. El texto de la sentencia no se procesa cuando se

precompila una aplicación. De hecho, el texto de la sentencia no tiene que existir

en el momento en que se precompila la aplicación. En su lugar, la sentencia de

SQL se trata como una variable del lenguaje principal con fines de precompilación

y se hace referencia a la variable durante la ejecución de la aplicación.

Se necesitan sentencias de soporte de SQL dinámico para transformar la variable

del lenguaje principal que contiene texto de SQL en un formato ejecutable.

Además, las sentencias de soporte de SQL dinámico funcionan en la variable del

lenguaje principal haciendo referencia al nombre de la sentencia. Estas sentencias

de soporte son:

EXECUTE IMMEDIATE

Prepara y ejecuta una sentencia que no utiliza ninguna variable del

lenguaje principal. Utilice esta sentencia como alternativa a las sentencias

PREPARE y EXECUTE.

Por ejemplo, considere la siguiente sentencia en C:

strcpy (qstring,"INSERT INTO WORK_TABLE SELECT *

FROM EMP_ACT WHERE ACTNO >= 100");

EXEC SQL EXECUTE IMMEDIATE :qstring;

PREPARE

Convierte el formato de serie de caracteres de la sentencia de SQL en un

formato ejecutable de la sentencia, asigna un nombre de sentencia y

opcionalmente coloca información sobre la sentencia en una estructura

SQLDA.

EXECUTE

Ejecuta una sentencia de SQL previamente preparada. La sentencia se

puede ejecutar repetidamente dentro de una conexión.

DESCRIBE

Coloca información sobre una sentencia preparada en una SQLDA.

Por ejemplo, considere la siguiente sentencia en C:

strcpy(hostVarStmt, "DELETE FROM org WHERE deptnumb = 15");

EXEC SQL PREPARE Stmt FROM :hostVarStmt;

EXEC SQL DESCRIBE Stmt INTO :sqlda;

EXEC SQL EXECUTE Stmt;

Nota: El contenido de las sentencias de SQL dinámico sigue la misma sintaxis que

las sentencias de SQL estático, con las siguientes excepciones:

v La sentencia no puede comenzar por EXEC SQL.


v La sentencia no puede finalizar con el terminador de sentencia. Una

excepción a esta norma es la sentencia CREATE TRIGGER, que puede

contener un signo de punto y coma (;).


v “Uso de SQL dinámico” en la página 18

v “Uso de SQL estático” en la página 16



v “Variables del lenguaje principal en aplicaciones de SQL incorporado” en la

página 74


v “Recuperación de información de variables del lenguaje principal procedente de

la estructura SQLDA en aplicaciones de SQL incorporado” en la página 152

v “Tipos de datos que se correlacionan con tipos de datos SQL en aplicaciones de

SQL incorporado” en la página 59

Tareas relacionadas:

v “Declaración de variables del lenguaje principal en aplicaciones de SQL


v “Cómo hacer referencia a variables del lenguaje principal en aplicaciones de SQL




Determinación del momento en que deben ejecutarse

sentencias de SQL estática o dinámicamente en aplicaciones

de SQL incorporado

Hay algunas consideraciones que deben tenerse en cuenta antes de determinar si

una sentencia de SQL se ejecuta estática o dinámicamente en una aplicación de

SQL incorporado. En las tablas siguientes se listan las consideraciones más

importantes a tener en cuenta, así como las recomendaciones relativas a cuándo se

debe utilizar SQL estático o dinámico, o bien en qué casos ambas opciones son

igualmente adecuadas.

Nota: Esta tabla contiene recomendaciones generales. El requisito de la aplicación,

el uso para el que esté pensada y el entorno de trabajo dictan la opción real.

Cuando tenga dudas, el mejor enfoque consiste en hacer prototipos de sus

sentencias como SQL estático, luego como SQL dinámico y comparar las

diferencias.

Tabla 1. Comparación entre SQL estático y dinámico

Consideraciones

Probablemente la

mejor opción

Tiempo deseado en el que debe ejecutarse la consulta:

v Menos de 2 segundos

v Entre 2 y 10 segundos

v Más de 10 segundos

v Estático

v Cualquiera

v Dinámico


Tabla 1. Comparación entre SQL estático y dinámico (continuación)

Consideraciones

Probablemente la

mejor opción

Uniformidad de datos que se consultan o con los que se trabaja por

parte de la sentencia de SQL

v Distribución de datos uniforme

v Ligera falta de uniformidad

v Distribución nada uniforme

v Estático

v Cualquiera

v Dinámico

Cantidad de predicados de rango en la consulta

v Pocos

v Algunos

v Muchos

v Estático

v Cualquiera

v Dinámico

Posibilidad de la ejecución de sentencias de SQL repetidas

v Se ejecuta muchas veces (10 o más)

v Se ejecuta unas cuantas veces (menos de 10)

v Se ejecuta una vez

v Cualquiera

v Cualquiera

v Estático

Naturaleza de la consulta

v Aleatoria

v Permanente

v Dinámico

v Cualquiera

Tipos de sentencias de SQL (DML/DDL/DCL)

v Proceso de transacciones (sólo DML)

v Mixto (DML y DDL - DDL afecta a los paquetes)

v Mixto (DML y DDL - DDL no afecta a los paquetes)

v Cualquiera

v Dinámico

v Cualquiera

Frecuencia con la que se emite el mandato RUNSTATS

v Muy poco frecuente

v Regular

v Frecuente

v Estático

v Cualquiera

v Dinámico

Las sentencias de SQL siempre se compilan antes de ejecutarlas. La diferencia

estriba en que las sentencias de SQL dinámico se compilan en tiempo de ejecución;

por eso, la aplicación puede ser un poco más lenta debido a la actividad general de

compilar cada sentencia dinámica en tiempo de ejecución de la aplicación, en

comparación con una única fase de compilación inicial, como sucede en el caso de

SQL estático.

En un entorno mixto, la opción entre SQL estático y dinámico debe depender

también de la frecuencia con la que se invalidan paquetes. Si el DDL no invalida

paquetes, SQL dinámico es más eficiente puesto que sólo las consultas ejecutadas

se recompilan cuando se utilizan la siguiente vez. Las otras no se recompilan. Para

SQL estático, el paquete entero se revincula cuando se ha invalidado.

En algunas ocasiones no importará mucho si se utiliza SQL estático o dinámico.

Por ejemplo, podría ser el caso de una aplicación que contenga básicamente

referencias a sentencias de SQL que deben ejecutarse dinámicamente, aunque

podría haber una sentencia que sería más adecuado ejecutarla como SQL estático.

En ese caso, para ser coherente con el código, podría tener más sentido

simplemente ejecutar también esa sentencia dinámicamente. Observe que las

consideraciones de la tabla anterior se listan en líneas generales por orden de

importancia.

No dé por supuesto que una versión estática de una sentencia de SQL se ejecuta

automáticamente más rápido que la misma sentencia procesada de forma

dinámica. En algunos casos, SQL estático es más rápido debido al proceso general

necesario para preparar la sentencia dinámica. En otros casos, la misma sentencia


preparada de forma dinámica se ejecuta más rápido, porque el optimizador puede

utilizar las estadísticas actuales de la base de datos en lugar de las estadísticas de

base de datos disponibles en el momento de la vinculación anterior. Observe que si

la transacción tarda menos de un par de segundos en completarse, SQL estático

suele ser más rápido. Para elegir qué método utilizar, debe crear un prototipo de

ambas formas de vinculación.

Nota: Tanto SQL estático como SQL dinámico vienen en dos tipos, sentencias que

utilizan variables del lenguaje principal y otras que no. Estos tipos son:

1. Sentencias de SQL estático que no contiene variables del lenguaje

principal

Esta es una situación poco probable que sólo verá para:

v Código de inicialización

v Sentencias de SQL muy simples

Las sentencias de SQL simples sin variables del lenguaje principal tienen

un buen rendimiento desde la perspectiva del rendimiento, puesto que

no hay proceso general de rendimiento en tiempo de ejecución y se

pueden aprovechar por completo las funciones del optimizador de DB2.

2. SQL estático que contiene variables del lenguaje principal

Las sentencias de SQL estático que utilizan variables del lenguaje

principal se consideran como el estilo tradicional de las aplicaciones de

DB2. Las sentencias de SQL estático evitan el proceso general en tiempo

de ejecución de una sentencia PREPARE y bloqueos de catálogo

adquiridos durante la compilación de sentencias. Desgraciadamente, no

se puede utilizar la potencia completa del optimizador porque este no

conoce la sentencia de SQL completa. Existe un problema particular con

distribuciones de datos nada uniformes.

3. SQL dinámico que no contiene marcadores de parámetros

Esto es normal en interfaces como CLP, que suele utilizarse para ejecutar

consultas para un propósito concreto. Desde la interfaz CLP, las

sentencias de SQL sólo se pueden ejecutar dinámicamente.

4. SQL dinámico que contiene marcadores de parámetros

La ventaja clave de las sentencias de SQL dinámico es que la presencia

de marcadores de parámetros permite amortizar el coste de la

preparación de la sentencia durante ejecuciones repetidas de la sentencia,

normalmente una sentencia SELECT o INSERT. Esta amortización es real

para todas las aplicaciones de SQL dinámico repetitivas.

Desgraciadamente, al igual que SQL estático con variables del lenguaje

principal, partes del optimizador de DB2 no funcionarán porque no está

disponible la información completa.

La recomendación es utilizar SQL estático con variables del lenguaje

principal o SQL dinámico sin marcadores de parámetros como las

opciones más eficientes.


v “Ejemplo de marcadores de parámetros en un programa de SQL ejecutado

dinámicamente” en la página 170

v “Vinculación de paquetes de SQL incorporado con una base de datos” en la

página 210



v “Cómo proporcionar entrada de variables a una sentencia de SQL ejecutada

dinámicamente mediante marcadores de parámetros” en la página 169

v “Configuración del entorno de desarrollo de SQL incorporado” en la página 12





Rendimiento de aplicaciones de SQL incorporado

El rendimiento es un factor importante a tener en cuenta cuando se desarrollan

aplicaciones de bases de datos. Las aplicaciones de SQL estático se pueden ejecutar

bien, porque dan soporte a la ejecución de sentencias de SQL estático y a una

combinación de ejecución de sentencias de SQL estático y dinámico. Debido a la

forma en que se compilan las sentencias de SQL estático, hay pasos que un

desarrollador o administrador de bases de datos debe seguir para asegurarse de

que las aplicaciones de SQL incorporado continúan ejecutándose bien con el

tiempo.

Los siguientes factores pueden afectar al rendimiento de las aplicaciones de SQL

incorporado:

v Cambios en esquemas de bases de datos con el tiempo

v Cambios en las cardinalidades de las tablas (el número de filas de las tablas) con

el tiempo

v Cambios en los valores de las variables del lenguaje principal vinculadas a

sentencias de SQL

El rendimiento de las aplicaciones de SQL incorporado se ve afectado por estos

factores porque el paquete se crea una vez cuando una base de datos puede tener

un determinado conjunto de características. Estas características intervienen en la

creación de los planes de acceso de tiempo de ejecución de paquetes, que definen

la forma en que el gestor de bases de datos ejecutará de la forma más eficiente

posible las sentencias de SQL. Con el tiempo, un esquema de base de datos y los

datos pueden cambiar, lo que hace que los planes de acceso de tiempo de ejecución

dejen de ser los óptimos. Esto puede dar lugar a una degradación del rendimiento

de la aplicación.

Por este motivo, es importante renovar periódicamente la información que se

utiliza para asegurar que los planes de acceso de tiempo de ejecución de los

paquetes se mantienen correctamente.

Se utiliza el mandato RUNSTATS para recopilar estadísticas actuales sobre tablas e

índices, especialmente si se ha producido una actividad de actualización

significativa o se han creado nuevos índices desde la última vez que se ejecutó el

mandato RUNSTATS. Esto proporciona al optimizador la información más precisa con

la que puede determinar el mejor plan de acceso.

El rendimiento de las aplicaciones de SQL incorporado se puede mejorar de varias

formas:

v Ejecutando el mandato RUNSTATS para actualizar estadísticas de base de datos.


v Volviendo a vincular paquetes de aplicación con la base de datos para volver a

generar los planes de acceso de tiempo de ejecución (basados en las estadísticas

actualizadas) que utilizará la base de datos para recuperar físicamente los datos

en disco.

v Utilizando la opción de enlace REOPT en los programas estáticos y dinámicos.


v “Improving performance by binding with REOPT” en Performance Guide

v “Query optimization using the REOPT bind option” en Performance Guide

v “Revinculación de paquetes existentes con el mandato REBIND” en la página

215


página 74

v “Mejoras en el rendimiento cuando se utiliza la opción REOPT del mandato

BIND” en la página 218

v “Utilización de registros especiales para controlar el entorno de compilación de

sentencias” en la página 214







v “API db2Runstats - Actualizar las estadísticas para tablas e índices” en Consulta

de las API administrativas

v “Mandato RUNSTATS” en Consulta de mandatos

Soporte de 32 bits y 64 bits para aplicaciones de SQL incorporado

Las aplicaciones de SQL incorporado se pueden crear en plataformas de 32 y de 64

bits. No obstante, existen consideraciones separadas sobre la creación y la

ejecución. Los scripts de construcción contienen una comprobación para determinar

el ancho de bits. Si el ancho de bits detectado es de 64 bits, se establece un

conjunto de conmutadores adicional para acomodar los cambios necesarios.

Los sistemas de base de datos DB2 están soportados en versiones de 32 y 64 bits

de los sistemas operativos listados más abajo. En la mayoría de estos sistemas

operativos existen diferencias respecto a la forma de crear aplicaciones de SQL

incorporado en los entornos de 32 y 64 bits.

v AIX

v HP-UX

v Linux

v Solaris

v Windows

Las únicas instancias de 32 bits que estarán soportadas en DB2 Versión 9 son:

v Linux en x86

v Windows en x86


v Windows en X64 (al utilizar la imagen de instalación de DB2 para Windows en

x86)

Las únicas instancias de 64 bits que estarán soportadas en DB2 Versión 9 son:

v AIX

v Sun

v HP PA-RISC

v HP IPF

v Linux en x86_64

v Linux en POWER

v Linux en zSeries

v Windows en X64 (al utilizar la imagen de instalación de Windows para X64)

v Windows en IPF

v Linux en IPF

Los sistemas de base de datos DB2 dan soporte a la ejecución de aplicaciones y

rutinas de 32 bits en todos los entornos de sistema operativo de 64 bits soportados

excepto Linux IA64 y Linux zSeries.

Para cada uno de los lenguajes principales, las variables del lenguaje principal

utilizadas pueden ser mejor en plataformas de 32 bits o 64 bits o ambas.

Compruebe los diversos tipos de datos para cada uno de los lenguajes de

programación.


v “Migración de las aplicaciones de SQL incorporado” en la página 269


v “Tipos de datos para procedimientos, funciones y métodos en aplicaciones de

SQL incorporado C y C++” en la página 65

v “Declaración de variables del lenguaje principal de tipo referencia de archivos en

aplicaciones de SQL incorporado C y C++” en la página 106

v “Declaración de variables del lenguaje principal de referencia de archivos

aplicaciones de SQL incorporado COBOL” en la página 128


aplicaciones de SQL incorporado FORTRAN” en la página 140

v “Declaración de variables del lenguaje principal de referencia de archivos en

aplicaciones de SQL incorporado REXX” en la página 148

Restricciones en aplicaciones SQL incorporadas

Restricciones sobre juegos de caracteres cuando se utiliza C

y C++ para programar aplicaciones de SQL incorporado

Algunos caracteres del juego de caracteres de C o C++ no están disponibles en

todos los teclados. Dichos caracteres se pueden entrar en un programa fuente C o

C++ utilizando una secuencia de tres caracteres denominada tri-grafo. Los tri-grafos

no se reconocen en las sentencias de SQL. El precompilador reconoce los tri-grafos

siguientes dentro de las declaraciones de variables del lenguaje principal:

Tri-grafo Definición


??( Corchete izquierdo '['

??) Corchete derecho ']'

??< Llave izquierda '{'

??> Llave derecha '}'

Los tri-grafos restantes que se listan a continuación se pueden producir en

cualquier lugar de un programa fuente C o C++:

Tri-grafo Definición

??= Almohadilla '#'

??/ Barra inclinada invertida '\'

??’ Signo de intercalación '^'

??! Barra vertical '|'

??– Tilde '~'



v “Variables del lenguaje principal en aplicaciones de SQL incorporado C y C++”

en la página 86


incorporado C y C++” en la página 88

v “Sección declare para variables del lenguaje principal en aplicaciones de SQL


v “Inicialización de variables del lenguaje principal en aplicaciones de SQL


v “Ejemplo: Plantilla de sección declare de SQL para aplicaciones de SQL



v “Ejemplos de C” en la página 405

v “Tipos de datos de SQL soportados en aplicaciones de SQL incorporado C y

C++” en la página 60



Restricciones en el uso de COBOL para programar


A continuación se describen las restricciones correspondientes a llamadas a API en

aplicaciones COBOL:

v Todas las variables enteras utilizadas como parámetros de valor en las llamadas

a las API se deben declarar con una cláusula USAGE COMP-5.

En un programa COBOL orientado a objetos:

v Sólo pueden aparecer sentencias de SQL en el primer programa o clase de una

unidad de compilación. Esta restricción se debe a que el precompilador inserta

datos de trabajo temporales en la primera sección Working-Storage que

encuentra.


v Cada clase que contenga sentencias de SQL debe tener una sección

Working-Storage a nivel de clase, aunque esté vacía. Esta sección se utiliza para

almacenar definiciones de datos generadas por el precompilador.




página 74

v “Variables del lenguaje principal en COBOL” en la página 119

v “Tablas de variables de indicador de nulo y de indicador de nulo o de

truncamiento en aplicaciones de SQL incorporado COBOL” en la página 132

v “Variables del lenguaje principal en FORTRAN” en la página 133


v “Tipos de datos de SQL soportados en aplicaciones de SQL incorporado

COBOL” en la página 67

v “Ejemplos de COBOL” en la página 408

Restricciones en el uso de FORTRAN para programar


El soporte de SQL incorporado de FORTRAN se ha estabilizado en DB2 UDB

Versión 5 y no se ha planificado ninguna mejora para el futuro. Por ejemplo, el

precompilador FORTRAN no puede manejar identificadores de objetos SQL, como

por ejemplo, los nombres de tabla, que tengan una longitud superior a 18 bytes.

Para utilizar las características incorporadas en los sistemas de bases de datos DB2

después de UDB Versión 5, como por ejemplo, los nombres de tabla de longitud

entre 19 y 128 bytes, debe escribir sus aplicaciones en un lenguaje que no sea

FORTRAN.

El desarrollo de aplicaciones de bases de datos FORTRAN no está soportado en

instancias de DB2 en entornos Windows o Linux.

FORTRAN no da soporte al acceso a bases de datos de varias hebras.

Algunos compiladores de FORTRAN tratan las líneas que contienen una 'D' o una

'd' en la columna 1 como líneas condicionales. Estas líneas se pueden compilar

para su depuración o se pueden tratar como comentarios. El precompilador

siempre tratará las líneas que contienen una 'D' o una 'd' en la columna 1 como

comentarios.

Algunos parámetros de las API requieren direcciones en lugar de valores en las

variables de llamada. El gestor de bases de datos proporciona las API GET

ADDRESS, DEREFERENCE ADDRESS y COPY MEMORY, que simplifican la

posibilidad de que el usuario proporcione estos parámetros.

Los elementos siguientes afectan al proceso de precompilación:

v El precompilador sólo admite dígitos, blancos y caracteres de tabulación en las

columnas 1-5 de las líneas de continuación.

v Las constantes Hollerith no se reciben soporte en archivos fuente .sqf.




v “Variables de indicador de nulo o de truncamiento en aplicaciones de SQL







FORTRAN” en la página 70

Restricciones en el uso de REXX para programar aplicaciones

de SQL incorporado

A continuación se describen las restricciones correspondientes a SQL incorporado

en aplicaciones REXX:

v El soporte de SQL de incorporado de REXX se ha estabilizado en DB2 UDB

Versión 5 y no se ha planificado ninguna mejora para el futuro. Por ejemplo,

REXX no puede manejar identificadores de objetos SQL, como por ejemplo, los

nombres de tabla, que tengan una longitud superior a 18 bytes. Para utilizar las

características incorporadas en los sistemas de bases de datos DB2 después de la

Versión 5, como por ejemplo, los nombres de tabla de longitud entre 19 y 128

bytes, debe escribir sus aplicaciones en un lenguaje que no sea REXX.

v En REXX/SQL no se soporta el SQL compuesto.

v REXX no da soporte a SQL estático.

v Las aplicaciones REXX no se soportan en los entornos EUC en japonés o chino

tradicional.





v “Consideraciones sobre la programación de aplicaciones REXX de SQL



v “Tipos de datos de SQL soportados en aplicaciones de SQL incorporado REXX”

en la página 72


Recomendaciones para desarrollar aplicaciones de SQL

incorporado con XML y XQuery

Las siguientes recomendaciones son válidas para usar XML y XQuery en


v Las aplicaciones deben acceder a todos los datos XML en formato de serie

serializada.

– Debe representar todos los datos, incluidos los datos numéricos y de fecha y

hora, en su formato de serie serializado.v Los datos XML externalizados están limitados a 2 GB.


v Todos los cursores que contengan datos XML son de no bloqueo (cada operación

de captación genera una petición del servidor de bases de datos).

v Cuando las variables del lenguaje principal de tipo carácter contienen datos

XML serializados, se da por supuesto que se utiliza la página de códigos de la

aplicación como la codificación de los datos y debe coincidir con cualquier

codificación interna existente en los datos.

v Debe especificar un tipo de datos LOB como el tipo base para una variable del

lenguaje principal XML.

v Se aplica lo siguiente a SQL estático:

– No se pueden utilizar variables del lenguaje principal de tipo carácter y

binarias para recuperar valores XML de una operación SELECT INTO.

– Si se espera un tipo de datos XML como entrada, el uso de las variables de

lenguaje principal CHAR, VARCHAR, CLOB y BLOB estará sujeto a una

operaciónn XMLPARSE con las características por omisión del manejo de

espacios en blanco (’STRIP WHITESPACE’). Cualquier otro tipo de variable del

lenguaje principal que no sea XML se rechazará.

– No hay soporte para las expresiones de XQuery estático; si se intenta

precompilar una expresión XQuery, la operación fallará con un error. Sólo

puede ejecutar expresiones XQuery a través de la función XMLQUERY.v Una expresión XQuery se puede ejecutar dinámicamente añadiendo a la

expresión la serie ″XQUERY″ como prefijo.


v “Errores y avisos procedentes de la precompilación aplicaciones de SQL


v “Ejemplo: cómo hacer referencia a variables del lenguaje principal XML en



v “Declaración de variables del lenguaje principal XML en aplicaciones de SQL


v “Ejecución de expresiones XQuery en aplicaciones de SQL incorporado” en la

página 166

Transacciones simultáneas y acceso a base de datos de varias hebras

en aplicaciones de SQL incorporado

Transacciones simultáneas y acceso a base de datos de

varias hebras en aplicaciones de SQL incorporado

Una característica de algunos sistemas operativos es la posibilidad de ejecutar

varias hebras de ejecución en un solo proceso. Las diversas hebras permiten que

una aplicación maneje sucesos asíncronos y facilitan la creación de aplicaciones

dirigidas por sucesos sin recurrir a esquemas de tramas. La siguiente información

explica cómo trabaja el DB2 gestor de bases de datos con varias hebras y se

relacionan algunas directrices de diseño que conviene recordar.

Si no está familiarizado con los términos relacionados con el desarrollo de

aplicaciones de varias hebras (como sección crítica y semáforo), consulte la

documentación sobre programación correspondiente al sistema operativo.


Una aplicación de SQL incorporado DB2 puede ejecutar sentencias de SQL para

varias hebras utilizando contextos. Un contexto es el entorno desde el que una

aplicación ejecuta todas las sentencias de SQL y las llamadas a las API. Todas las

conexiones, unidades de trabajo y otros recursos de base de datos están asociados

a un contexto específico. Cada contexto está asociado a una o más hebras de una

aplicación. El desarrollo de aplicaciones de SQL incorporado de varias hebras con

código con protección de hebras sólo recibe soporte en C y C++. Puede escribir su

propio compilador, que junto con las funciones que proporciona el lenguaje

permita el acceso simultáneo a bases de datos de varias hebras.

Para cada sentencia de SQL ejecutable en un contexto, la primera llamada a los

servicios de tiempo de ejecución siempre intenta obtener un enganche. Si esta

operación resulta satisfactoria, prosigue el proceso. Si no lo es (porque una

sentencia de SQL de otra hebra del mismo contexto ya tiene el enganche), se

bloquea la llamada en un semáforo de señalización hasta que entra en funciones

dicho semáforo, en cuyo momento la llamada obtiene el enganche y prosigue el

proceso. Se mantiene en enganche hasta que se ha completado el proceso,

momento en que lo libera la última llamada a los servicios de tiempo de ejecución

que se ha generado para esa sentencia de SQL en particular.

El resultado neto es que cada sentencia de SQL de un contexto se ejecuta como una

unidad atómica, aunque puede que haya otras hebras que estén intentando

ejecutar sentencias de SQL al mismo tiempo. Esta acción asegura que las distintas

hebras que puedan actuar a la vez no alteran las estructuras internas de los datos.

Las API también utilizan el enganche utilizado por los servicios de tiempo de

ejecución; por consiguiente, las API tienen las mismas restricciones que las rutinas

de los servicios de tiempo de ejecución dentro de cada contexto.

En un proceso, se pueden intercambiar contextos entre hebras, pero no se pueden

intercambiar entre procesos. Un uso de varios contextos consiste en proporcionar

soporte de transacciones simultáneas.

En la implementación por omisión de las aplicaciones de hebras sobre una base de

datos DB2, la serialización del acceso a la base de datos se impone mediante las

API de la base de datos. Si una hebra realiza una llamada a la base de datos, las

llamadas realizadas por otras hebras se bloquearán hasta que finalice la primera

llamada, aunque las siguientes llamadas accedan a objetos de la base de datos que

no estén relacionados con la primera llamada. Además, todas las hebras de un

proceso comparten un ámbito de confirmación. El verdadero acceso simultáneo a

una base de datos sólo se puede conseguir mediante procesos separados o

utilizando las API que se describen en este tema.

Los sistemas de bases de datos DB2 proporcionan API que se pueden utilizar para

asignar y manipular entornos separados (contextos) para el uso de las API de la

base de datos y SQL incorporado. Cada contexto es una entidad separada y

cualquier conexión o enlace realizado mediante un contexto es independiente de

los demás contextos (por lo tanto, de las demás conexiones o enlaces de un

proceso). Para poder trabajar sobre un contexto, primero se debe asociar a una

hebra. Una hebra siempre debe tener un contexto cuando se realizan llamadas a las

API de la base de datos o cuando se utiliza SQL incorporado.

Por omisión, todas las aplicaciones del sistema de bases de datos DB2 son de

varias hebras y pueden utilizar varios contextos. Puede utilizar las siguientes API

de DB2 para utilizar varios contextos. Específicamente, su aplicación puede crear

un contexto para una hebra, conectarse o desconectarse de un contexto


independiente para cada hebra y pasar contextos entre las hebras. Si su aplicación

no llama a ninguna de estas API, DB2 administrará automáticamente los contextos

múltiples para sus aplicaciones:

v sqleAttachToCtx - Enlazar a contexto

v sqleBeginCtx - Crear y enlazar a un contexto de aplicación

v sqleDetachFromCtx - Desenlazar de contexto

v sqleEndCtx - Desenlazar y destruir contexto de aplicación

v sqleGetCurrentCtx - Obtener contexto actual

v sqleInterruptCtx - Interrumpir contexto

Esas API no tienen efecto (es decir, son no-ops) sobre las plataformas que no dan

soporte a hebras de aplicaciones.

Los contextos se tienen que asociar a una determinada hebra durante el tiempo

que dure una conexión o enlace. Una hebra puede enlazarse a un contexto,

conectarse a una base de datos, desenlazarse del contexto y luego una segunda

hebra se puede enlazar al contexto y continuar trabajando utilizando la conexión

de base de datos existente. Los contextos se pueden pasar entre hebras de un

proceso, pero no entre procesos.

Aunque se utilicen las nueva API, las siguientes API continúan estando

serializadas:

v sqlabndx - Vincular

v sqlaprep - Precompilar programa

v sqluexpr - Exportar

v db2Import y sqluimpr - Importar

Notas:

1. La CLI de DB2 utiliza automáticamente múltiples contextos para conseguir

acceso con protección de hebras y simultáneo a la base de datos en las

plataformas que dan soporte a varias hebras. Aunque no resulta recomendable

para DB2, los usuarios pueden inhabilitar de forma explícita esta función si lo

desean.

2. Por omisión, AIX no permite que las aplicaciones de 32 bits se enlacen a más

de 11 segmentos de memoria compartida por proceso, de los cuales un máximo

de 10 se pueden utilizar para conexiones de DB2.

Cuando se alcanza este límite, DB2 devuelve SQLCODE -1224 en SQL

CONNECT. DB2 Connect también tiene un límite de 10 conexiones si los

usuarios locales ejecutan confirmación de dos fases sobre SNA o confirmación

de dos cases con TP Monitor (SNA o TCP/IP).

Se puede utilizar la variable de entorno de AIX EXTSHM para aumentar el

número máximo de segmentos de memoria compartida a los que se puede

enlazar un proceso.

Para utilizar EXTSHM con DB2, haga lo siguiente:

En sesiones cliente:

export EXTSHM=ON

Cuando se inicie el servidor de DB2:

export EXTSHM=ON

db2set DB2ENVLIST=EXTSHM

db2start

En DPF, añada también las siguientes líneas a los archivos userprofile o

usercshrc:


EXTSHM=ON

export EXTSHM

Una alternativa consiste en mover la base de datos local o DB2 Connect a otra

máquina y acceder a la misma de forma remota, o acceder a la base de datos

de DB2 Connect con retorno de bucle TCP/IP, catalogándolo como un nodo

remoto que tiene la dirección TCP/IP de la máquina local.


v “Transacciones simultáneas” en Desarrollo de SQL y rutinas externas

v “Recomendaciones para utilizar varias hebras” en la página 34

v “Ejecución de sentencias de SQL en aplicaciones de SQL incorporado” en la

página 150


v “API de personalización del precompilador” en Consulta de las API

administrativas

v “API sqleAttachToCtx - Enlazar con contexto” en Consulta de las API

administrativas

v “API sqleBeginCtx - Crear y enlazar con un contexto de aplicación” en Consulta

de las API administrativas

v “API sqleDetachFromCtx - Desenlazar del contexto” en Consulta de las API

administrativas

v “API sqleEndCtx - Desenlazar y liberar la memoria asociada con un contexto de

aplicación” en Consulta de las API administrativas

v “API sqleGetCurrentCtx - Obtener contexto actual” en Consulta de las API

administrativas

v “API sqleInterruptCtx - Interrumpir contexto” en Consulta de las API

administrativas

v “API sqleSetTypeCtx - Establecer tipo de contexto de aplicación” en Consulta de

las API administrativas

v “API de administración y migración de aplicaciones” en Consulta de las API

administrativas

v “API y estructuras de datos modificadas” en Consulta de las API administrativas

Ejemplos relacionados:

v “dbthrds.sqc -- How to use multiple context APIs on UNIX (C)”

v “dbthrds.sqC -- How to use multiple context APIs on UNIX (C++)”

Recomendaciones para utilizar varias hebras

Cuando acceda a una base de datos desde aplicaciones de varias hebras, siga estas

directrices:

Coloque en serie la alteración de estructuras de datos.

Las aplicaciones se deben asegurar de que las estructuras de datos,

definidas por el usuario y utilizadas por las sentencias de SQL y por las

rutinas del gestor de bases de datos, no se vean alteradas por una hebra

mientras se esté procesando una sentencia de SQL o una rutina del gestor

de bases de datos en otra hebra. Por ejemplo, no permita que una hebra

reasigne una SQLDA mientras la está utilizando una sentencia de SQL en

otra hebra.


Considere la posibilidad de utilizar estructuras de datos separadas.

Puede resultar más fácil asignar a cada hebra sus propias estructuras de

datos definidas por el usuario, a fin de evitar que se coloque en serie su

uso. Esta directriz es especialmente cierta para la SQLCA, la cual utilizan

no sólo todas las sentencias de SQL ejecutables, sino también todas las

rutinas del gestor de bases de datos. Existen tres alternativas para evitar

este problema con la SQLCA:

v Utilice EXEC SQL INCLUDE SQLCA, pero añada struct sqlca sqlca al

comienzo de cualquier rutina que utilice cualquier hebra que no sea la

primera.

v Coloque EXEC SQL INCLUDE SQLCA dentro de cada rutina que contenga

SQL, en lugar de hacerlo en el ámbito global.

v Sustituya EXEC SQL INCLUDE SQLCA por #include "sqlca.h" y luego

añada "struct sqlca sqlca" al comienzo de cualquier rutina que utilice

SQL.




v “Resolución de problemas de aplicaciones de SQL incorporado de varias hebras”

en la página 36

Consideraciones sobre la página de códigos y el código de

país o región para aplicaciones UNIX de varias hebras

Esta sección es específica de las aplicaciones de SQL incorporado C y C++.

En AIX, el entorno operativo Solaris y HP-UX, las funciones que se utilizan para

las consultas en tiempo de ejecución de la página de códigos y del código de país

o región que se van a utilizar para una conexión de base de datos tienen ahora

protección de hebras. Pero estas funciones pueden crear cierta contención de

bloqueo (lo que da lugar a una degradación del rendimiento) en una aplicación de

varias hebras que utilice un gran número de conexiones simultáneas de base de

datos.

Puede utilizar la variable de entorno DB2_FORCE_NLS_CACHE para eliminar la

posibilidad de que se produzca contención de bloqueo en aplicaciones de varias

hebras. Cuando DB2_FORCE_NLS_CACHE tiene el valor TRUE, la información sobre

página de códigos y código de país o región se guarda la primera vez que una

hebra accede a la misma. A partir de este punto, cualquier otra hebra que solicite

esta información utilizará la que se encuentra en la antememoria. Guardando esta

información, se suprime la contención de bloqueos y, en determinadas situaciones,

se obtiene una mejora en el rendimiento.

No debe asignar a DB2_FORCE_NLS_CACHE el valor TRUE si la aplicación

cambia los valores de entorno nacional entre conexiones. Si se produce esta

situación, se devolverá la información del entorno nacional original aunque se

hayan cambiado estos valores. En general, las aplicaciones de varias hebras no

cambiarán los valores de entorno nacional, lo cual asegura que la aplicación sigue

estando a salvo de hebras.


v “DB2 registry and environment variables” en Performance Guide


v “Conexión con bases de datos DB2 en aplicaciones de SQL incorporado” en la

página 58

v “Desconexión de aplicaciones de SQL incorporado” en la página 195



Resolución de problemas de aplicaciones de SQL incorporado

de varias hebras

Las secciones siguientes describen problemas que se pueden producir con

aplicaciones de SQL incorporado de varias hebras y cómo evitarlos.

Una aplicación que utiliza varias hebras es más compleja que una aplicación de

una sola hebra. Esta complejidad adicional puede conducir potencialmente a

algunos problemas inesperados. Cuando escriba una aplicación de varias hebras,

tenga precaución con lo siguiente:

Dependencias de base de datos entre dos o más contextos.

Cada contexto de una aplicación tiene sus propios recursos de base de

datos, incluidos los bloqueos sobre objetos de base de datos. Esta

característica posibilita que dos contextos, si están accediendo al mismo

objeto de base de datos, lleguen a un punto muerto. El gestor de bases de

datos puede detectar el punto muerto, uno de los contextos recibirá

SQLCODE -911 y su unidad de trabajo se retrotraerá.

Dependencias de aplicaciones entre dos o más contextos.

Tenga cuidado con las técnicas de programación que establecen

dependencias entre contextos. Los enganches, los semáforos y las secciones

críticas son ejemplos de técnicas de programación que pueden establecer

dichas dependencias. Si una aplicación tiene dos contextos que tienen

dependencias, tanto de aplicación como de base de datos, entre los

contextos, es posible que la aplicación llegue a un punto muerto. Si

algunas de las dependencias están fuera del gestor de bases de datos, no se

detecta el punto muerto, por lo que la aplicación se suspende o se cuelga.

Prevención de puntos muertos para varios contextos.

Puesto que el gestor de bases de datos no detecta puntos muertos entre

hebras, diseñe y codifique la aplicación de modo que impida (o al menos

evite) puntos muertos.

Como ejemplo de un punto muerto que el gestor de bases de datos no

detectaría piense en una aplicación que tiene dos contextos y ambos

acceden a una estructura de datos común. Para evitar problemas en que

ambos contextos cambien simultáneamente la estructura de datos, la

estructura de datos se protege mediante un semáforo. Los contextos tienen

el aspecto siguiente:

contexto 1

SELECT * FROM TAB1 FOR UPDATE....

UPDATE TAB1 SET....

get semaphore

access data structure

release semaphore

COMMIT

contexto 2

get semaphore


access data structure

SELECT * FROM TAB1...

release semaphore

COMMIT

Suponga que el primer contexto ejecuta satisfactoriamente las sentencias

SELECT y UPDATE, mientras que el segundo contexto obtiene el semáforo

y accede a la estructura de datos. Ahora, el primer contexto intenta obtener

el semáforo, pero no puede porque el segundo contexto lo está reteniendo.

A continuación, el segundo contexto intenta leer una fila de la tabla TAB1,

pero se detiene en un bloqueo de la base de datos mantenido por el primer

contexto. La aplicación se encuentra ahora en un estado en que el contexto

1 no puede terminar antes de que lo haga el contexto 2, y el contexto 2 está

esperando a que el contexto 1 termine. La aplicación está en un punto

muerto pero, puesto que el gestor de bases de datos no sabe nada de la

dependencia del semáforo, no se retrotraerá ninguno de los contextos. La

dependencia no resuelta deja la aplicación suspendida.

Puede evitar el punto muerto que se produciría en el ejemplo anterior de

varias formas.

v Libere todos los bloqueos mantenidos antes de obtener el semáforo.

Cambie el código del contexto 1 de forma que realice una confirmación

antes de obtener el semáforo.

v No codifique sentencias de SQL en una sección protegida por semáforos.

Cambie el código del contexto 2 de forma que libere el semáforo antes

de ejecutar SELECT.

v Codifique todas las sentencias de SQL dentro de semáforos.

Cambie el código del contexto 1 de forma que obtenga el semáforo antes

de ejecutar la sentencia SELECT. Aunque esta técnica funcionará, no es

muy recomendable, puesto que los semáforos colocarán en serie el

acceso al gestor de bases de datos, lo cual invalidará potencialmente las

ventajas de utilizar varias hebras.

v Establezca el parámetro de configuración de la base de datos locktimeout

en un valor distinto de -1.

Aunque un valor distinto de -1 no impedirá el punto muerto, permitirá

que se reanude la ejecución. Eventualmente, se retrotraerá el contexto 2,

puesto que no puede obtener el bloqueo solicitado. Cuando maneje el

error de retrotracción, el contexto 2 debe liberar el semáforo. Una vez

que se haya liberado el semáforo, el contexto 1 podrá continuar y el

contexto 2 será libre de reintentar su trabajo.

Las técnicas para evitar puntos muertos se describen en términos del

ejemplo, pero las puede aplicar a todas las aplicaciones de varias hebras.

En general, trate el gestor de bases de datos tal como trataría cualquier

recurso protegido y no experimentará problemas con las aplicaciones de

varias hebras.


v “Información de error en los campos SQLCODE, SQLSTATE y SQLWARN” en la

página 190





v “Inclusión de las variables del lenguaje principal SQLSTATE y SQLCODE en



Capítulo 3. Programación de aplicaciones de SQL

incorporado

Programación de aplicaciones de SQL incorporado 42

Archivos fuente de SQL incorporado . . . . . . 43

Plantilla de aplicación de SQL incorporado en C . . 44


aplicaciones de SQL incorporado . . . . . . . 47

Archivos de inclusión y definiciones necesarios

para aplicaciones de SQL incorporado . . . . 47


incorporado C y C++ . . . . . . . . . . 48


incorporado COBOL . . . . . . . . . . 50


incorporado FORTRAN . . . . . . . . . 53

Declaración de la SQLCA para el manejo de errores 56

Manejo de errores utilizando la sentencia

WHENEVER . . . . . . . . . . . . . . 57

Conexión con bases de datos DB2 en aplicaciones de

SQL incorporado . . . . . . . . . . . . 58


datos SQL en aplicaciones de SQL incorporado . . 59


datos SQL en aplicaciones de SQL incorporado . 59


aplicaciones de SQL incorporado C y C++ . . . 60


aplicaciones de SQL incorporado C y C++ . . 60

Tipos de datos para procedimientos, funciones

y métodos en aplicaciones de SQL

incorporado C y C++ . . . . . . . . . 65


aplicaciones de SQL incorporado COBOL . . . 67


aplicaciones de SQL incorporado FORTRAN . . 70


aplicaciones de SQL incorporado REXX . . . . 72

Variables del lenguaje principal en aplicaciones de

SQL incorporado . . . . . . . . . . . . 74






con el Generador de declaraciones db2dclgn . . 77

Tipos de datos de columna y variables del


incorporado . . . . . . . . . . . . . 77


XML en aplicaciones de SQL incorporado . . . 79

Identificar valores XML en una SQLDA . . . . 80

Identificación de valores de SQL nulos con

variables de indicador de nulo . . . . . . . 81

Inclusión de las variables del lenguaje principal

SQLSTATE y SQLCODE en aplicaciones de SQL

incorporado . . . . . . . . . . . . . 83

Cómo hacer referencia a variables del lenguaje

principal en aplicaciones de SQL incorporado . . 84

Ejemplo: cómo hacer referencia a variables del

lenguaje principal XML en aplicaciones de SQL

incorporado . . . . . . . . . . . . . 85


de SQL incorporado C y C++ . . . . . . . 86

Variables del lenguaje principal en


Nombres de variables del lenguaje principal

en aplicaciones de SQL incorporado C y C++ . 88

Sección declare para variables del lenguaje

principal en aplicaciones de SQL incorporado

C y C++ . . . . . . . . . . . . . 89

Ejemplo: Plantilla de sección declare de SQL

para aplicaciones de SQL incorporado C y

C++ . . . . . . . . . . . . . . . 90

Variables SQLSTATE y SQLCODE en una

aplicación de SQL incorporado C y C++ . . . 92

Declaración de variables numéricas del


incorporado C y C++ . . . . . . . . . 92


de tipo carácter de longitud fija, terminadas

en nulo y de longitud variable en aplicaciones

de SQL incorporado C y C++ . . . . . . 94

Declaración de variables de tipo graphic del


incorporado C y C++ . . . . . . . . . 96

Tipos de datos wchar_t y sqldbchar para datos

gráficos en aplicaciones de SQL incorporado C

y C++ . . . . . . . . . . . . . . 97

Opción del precompilador WCHARTYPE para

datos gráficos en aplicaciones de SQL

incorporado C y C++ . . . . . . . . . 98

Declaración de variables del lenguaje

principal de tipo VARGRAPHIC en el

formato estructurado en aplicaciones de SQL

incorporado C o C++ . . . . . . . . . 101

Declaración de variables de tipo GRAPHIC

del lenguaje principal en formatos de un solo

gráfico y de gráficos terminados en nulo en



principal de tipo objeto grande (large object)

en aplicaciones de SQL incorporado C y C++ . 103


principal de tipo localizador de objeto grande

(large object locator) en aplicaciones de SQL

incorporado C y C++ . . . . . . . . . 105


principal de tipo referencia de archivos en




principal como punteros en aplicaciones de

SQL incorporado C y C++ . . . . . . . 107

Declaración de miembros de datos de clase

como variables del lenguaje principal en

aplicaciones de SQL incorporado C++ . . . 108

Resolución de ámbito y operaciones de

miembro de clase en aplicaciones de SQL

incorporado C y C++ . . . . . . . . . 110

Consideraciones sobre EUC en japonés o

chino tradicional y UCS-2 en aplicaciones de


Almacenamiento binario de valores de

variables mediante la cláusula FOR BIT

DATA en aplicaciones de SQL incorporado C

y C++ . . . . . . . . . . . . . . 112

Inicialización de variables del lenguaje


C y C++ . . . . . . . . . . . . . 112

Expansión de macros y DECLARE SECTION

de aplicaciones de SQL incorporado C y C++ . 112

Soporte de estructuras del lenguaje principal

en la sección de declaración de aplicaciones

de SQL incorporado C y C++ . . . . . . 114

Variables de indicador de nulo o de

truncamiento y tablas de indicadores en


Series terminadas en nulo en aplicaciones de


Variables del lenguaje principal en COBOL . . 119

Variables del lenguaje principal en COBOL 119


en COBOL . . . . . . . . . . . . 119



COBOL . . . . . . . . . . . . . 120


para aplicaciones de SQL incorporado

COBOL . . . . . . . . . . . . . 120

Tipos de datos BINARY/COMP-4 en

aplicaciones de SQL incorporado COBOL . . 121

Variables SQLSTATE y SQLCODE en




incorporado COBOL . . . . . . . . . 122


principal de tipo carácter de longitud fija y

longitud variable en aplicaciones de SQL



principal de tipo graphic de longitud fija y





en aplicaciones de SQL incorporado COBOL . 126






principal de referencia de archivos


Agrupación de elementos de datos utilizando

REDEFINES en aplicaciones de SQL



chino tradicional y UCS-2 para aplicaciones

de SQL incorporado COBOL . . . . . . 129

Almacenamiento binario de valores de

variables mediante la cláusula FOR BIT

DATA en aplicaciones de SQL incorporado

COBOL . . . . . . . . . . . . . 129

Soporte de estructuras del lenguaje principal

en la sección de declaración de aplicaciones

de SQL incorporado COBOL . . . . . . 130

Tablas de variables de indicador de nulo y de

indicador de nulo o de truncamiento en


Variables del lenguaje principal en FORTRAN 133

Variables del lenguaje principal en

FORTRAN . . . . . . . . . . . . 133



FORTRAN . . . . . . . . . . . . 133



FORTRAN . . . . . . . . . . . . 134


para aplicaciones de SQL incorporado

FORTRAN . . . . . . . . . . . . 134

Variables SQLSTATE y SQLCODE en

aplicaciones de SQL incorporado FORTRAN . 135



incorporado FORTRAN . . . . . . . . 135


principal de tipo carácter de longitud fija y






FORTRAN . . . . . . . . . . . . 138






principal de referencia de archivos


Consideraciones sobre los juegos de

caracteres gráficos (de varios bytes) en



chino tradicional y UCS-2 para aplicaciones

de SQL incorporado FORTRAN . . . . . 141


truncamiento en aplicaciones de SQL




de SQL incorporado REXX . . . . . . . . 142

Variables del lenguaje principal en REXX . . 142


en aplicaciones de SQL incorporado REXX . 142

Referencias a variables del lenguaje principal


Variables de REXX predefinidas . . . . . 143

Consideraciones sobre la programación de

aplicaciones REXX de SQL incorporado . . 145







incorporado REXX . . . . . . . . . . 147


principal de referencia de archivos en

aplicaciones de SQL incorporado REXX . . 148

Borrado de variables del lenguaje principal

de LOB en aplicaciones de SQL incorporado . 149


truncamiento en aplicaciones de SQL

incorporado REXX . . . . . . . . . . 149

Ejecución de sentencias de SQL en aplicaciones de

SQL incorporado . . . . . . . . . . . . 150

Ejecución de sentencias de SQL en aplicaciones


Comentarios en aplicaciones de SQL

incorporado . . . . . . . . . . . . . 150

Ejecución de sentencias de SQL estático en



lenguaje principal procedente de la estructura

SQLDA en aplicaciones de SQL incorporado . . 152


lenguaje principal procedente de la

estructura SQLDA en aplicaciones de SQL

incorporado . . . . . . . . . . . . 152

Declaración de la estructura SQLDA en un

programa de SQL ejecutado dinámicamente . 153

Preparación de una sentencia de SQL

ejecutada dinámicamente utilizando la

estructura SQLDA mínima . . . . . . . 154

Asignación de una estructura SQLDA con

suficientes entradas SQLVAR para sentencias

de SQL ejecutadas dinámicamente . . . . 156

Descripción de una sentencia SELECT en un


Adquisición de almacenamiento para

albergar una fila . . . . . . . . . . 158

Proceso del cursor en un programa SQL

ejecutado dinámicamente . . . . . . . 159

Asignación de una estructura SQLDA para

un programa de SQL ejecutado

dinámicamente . . . . . . . . . . . 159

Transferencia de datos en un programa de

SQL ejecutado dinámicamente utilizando una

estructura SQLDA . . . . . . . . . . 163

Proceso de sentencias de SQL interactivas en

programas de SQL ejecutados dinámicamente 164

Determinación del tipo de sentencia en

programas de SQL ejecutados dinámicamente 164

Proceso de sentencias SELECT de lista de

variables en programas de SQL ejecutados

dinámicamente . . . . . . . . . . . 165

Cómo guardar peticiones de SQL

procedentes de usuarios finales . . . . . 166

Ejecución de expresiones XQuery en


Suministro de entrada de variables a un SQL

ejecutado dinámicamente mediante marcadores

de parámetros . . . . . . . . . . . . 169

Cómo proporcionar entrada de variables a

una sentencia de SQL ejecutada

dinámicamente mediante marcadores de

parámetros . . . . . . . . . . . . 169

Ejemplo de marcadores de parámetros en un





aplicaciones de SQL incorporado . . . . . 171



Llamada a procedimientos almacenados

desde REXX . . . . . . . . . . . . 172


desplazamiento por los mismos en aplicaciones



desplazamiento por los mismos en

aplicaciones de SQL incorporado . . . . . 176

Desplazamiento por datos anteriormente

recuperados en aplicaciones de SQL

incorporado . . . . . . . . . . . . 177

Mantenimiento de una copia de datos

captados aplicaciones de SQL incorporado . 177

Recuperación de datos captados por segunda

vez en aplicaciones de SQL incorporado . . 178

Diferencias en el orden de las filas en tablas

de resultados . . . . . . . . . . . 179

Actualización de datos anteriormente

recuperados en aplicaciones de SQL

incorporado . . . . . . . . . . . . 180

Selección de varias filas mediante un cursor 180

Actualización y supresión de datos

recuperados en una aplicación de SQL

ejecutada estáticamente . . . . . . . . 188

Ejemplo de captación en un programa de

SQL ejecutado estáticamente . . . . . . 189

Recuperación de mensajes de error en aplicaciones


Información de error en los campos SQLCODE,

SQLSTATE y SQLWARN . . . . . . . . 190

Recuperación de mensajes de error en


Consideraciones sobre las rutinas de lista de

salida . . . . . . . . . . . . . . . 194

Capítulo 3. Programación de aplicaciones de SQL incorporado 41

Consideraciones sobre el manejador de

excepciones, señales e interrupciones . . . . 194

Desconexión de aplicaciones de SQL incorporado 195

Programación de aplicaciones de SQL incorporado

La programación de aplicaciones de SQL incorporado implica todos los pasos

necesarios para ensamblar una aplicación en el lenguaje elegido de programación

de SQL incorporado. Una vez determine que SQL incorporado es la API adecuada

para sus necesidades de programación, y tras diseñar la aplicación de SQL

incorporado, estará preparado para programar una aplicación de SQL incorporado.

Requisitos previos:

v Elección de si desea utilizar sentencias de SQL estático o dinámico

v Diseño de una aplicación de SQL incorporado

La programación de aplicaciones de SQL incorporado consta de las siguientes

subtareas:

v Inclusión de los archivos de cabecera necesarios

v Elección de un lenguaje de programación de SQL incorporado soportado

v Declaración de variables del lenguaje principal para representar los valores que

se van a incluir en sentencias de SQL

v Conexión con una fuente de datos

v Ejecución de sentencias de SQL

v Manejo de errores y avisos de SQL relacionados con la ejecución de sentencias

de SQL

v Desconexión de la fuente de datos

Cuando haya completado la aplicación de SQL incorporado, estará listo para

compilar y ejecutar la aplicación: Creación de aplicaciones de SQL incorporado.


v “Archivos de inclusión y definiciones necesarios para aplicaciones de SQL



página 74


página 150









Archivos fuente de SQL incorporado

Cuando desarrolla código fuente que incluye SQL incorporado, tiene que seguir

ciertos convenios de denominación de archivos específicos para cada uno de los

lenguajes principales soportados.

Archivos de entrada y de salida para C y C++:

Por omisión, la aplicación fuente puede tener las siguientes extensiones:

.sqc Para archivos C en todos los sistemas operativos soportados

.sqC Para archivos C++ en los sistemas operativos UNIX y Linux

.sqx Para archivos C++ en sistemas operativos Windows

Por omisión, los archivos de salida del precompilador correspondiente tienen las

siguientes extensiones:

.c Para archivos C en todos los sistemas operativos soportados

.C Para archivos C++ en los sistemas operativos UNIX y Linux

.cxx Para archivos C++ en sistemas operativos Windows

Puede utilizar la opción de precompilación OUTPUT para alterar temporalmente el

nombre y la vía de acceso del archivo fuente de salida modificado. Si utiliza las

opciones de precompilación TARGET C o TARGET CPLUSPLUS, no es necesario que el

archivo de entrada tenga ninguna extensión concreta.

Archivos de entrada y salida para COBOL:

Por omisión, la aplicación fuente tiene la extensión:

.sqb Para archivos COBOL en todos los sistemas operativos

Sin embargo, si utiliza la opción de precompilación TARGET, (TARGET

ANSI_COBOL, TARGET IBMCOB o TARGET MFCOB), el archivo de entrada

puede tener la extensión que prefiera.



.cbl Para archivos COBOL en todos los sistemas operativos

Sin embargo, puede utilizar la opción de precompilación OUTPUT para especificar

un nuevo nombre y vía de acceso para el archivo fuente modificado de salida.

Archivos de entrada y salida para FORTRAN:

Por omisión, la aplicación fuente tiene la extensión:

.sqf Para archivos FORTRAN en todos los sistemas operativos

Sin embargo, si utiliza la opción de precompilación TARGET con la opción

FORTRAN, el archivo de entrada puede tener la extensión que prefiera.




.f Para archivos FORTRAN en los sistemas operativos UNIX y Linux

.for Para archivos FORTRAN en sistemas operativos Windows

Sin embargo, puede utilizar la opción de precompilación OUTPUT para especificar

un nuevo nombre y vía de acceso para el archivo fuente modificado de salida.





v “Creación de aplicaciones de SQL incorporado desde la línea de mandatos” en la

página 268

Plantilla de aplicación de SQL incorporado en C

Esta es una aplicación de SQL incorporado simple que se le proporciona para

probar el entorno de desarrollo de SQL incorporado y como ayuda para aprender

la estructura básica de las aplicaciones de SQL incorporado.

Las aplicaciones de SQL incorporado requieren la siguiente estructura:

v inclusión de los archivos de cabecera necesarios

v declaraciones de variables del lenguaje principal para los valores que se van a

incluir en sentencias de SQL

v una conexión de base de datos

v la ejecución de sentencias de SQL

v el manejo de errores y avisos de SQL relacionados con la ejecución de sentencias

de SQL

v desconexión de la conexión de base de datos

El siguiente código fuente demuestra la estructura básica necesaria para las

aplicaciones de SQL incorporado escritas en C.


#include <stdio.h> �1�

#include <stdlib.h>

#include <string.h>

#include <sqlenv.h>

#include <sqlutil.h>

EXEC SQL BEGIN DECLARE SECTION; �2�

short id;

char name[10];

short dept;

double salary;

char hostVarStmtDyn[50];

EXEC SQL END DECLARE SECTION;

int main()

{

int rc = 0; �3�

EXEC SQL INCLUDE SQLCA; �4�

/* conectar con base de datos */

printf("\n Connecting to database...");

EXEC SQL CONNECT TO "sample"; �5�

if (SQLCODE < 0) �6�

{

printf("\nConnect Error: SQLCODE = %ld \n", SQLCODE);

goto connect_reset;

}

else

{

printf("\n Connected to database.\n");

}

/* ejecutar una sentencia SQL (consulta) mediante SQL estático; copiar

la fila de valores de resultado a variables del lenguaje principal*/

EXEC SQL SELECT id, name, dept, salary �7�

INTO :id, :name, :dept, :salary



{

printf("Select Error: SQLCODE = %ld \n", SQLCODE);

}

else

{

/* imprimir los valores de variable del lenguaje principal a

salida estándar */

printf("\n Executing a static SQL query statement, searching for

\n the id value equal to 310\n");

printf("\n ID Name DEPT Salary\n");

printf(" %3d %7s %7d %16.2f\n\n", id, name, dept, salary);

}

strcpy(hostVarStmtDyn, "UPDATE staff

SET salary = salary + 1000

WHERE dept = ?");

/* ejecutar una sentencia de SQL (operación) utilizando una variable del

lenguaje principal y DYNAMIC SQL*/

EXEC SQL PREPARE StmtDyn FROM :hostVarStmtDyn;


{

printf("Prepare Error: SQLCODE = %ld \n", SQLCODE);

}

else

{

EXEC SQL EXECUTE StmtDyn USING :dept; �8�

}


{

printf("Execute Error: SQLCODE = %ld \n", SQLCODE);

}

Figura 1. Programa de ejemplo: template.sqc (Parte 1 de 2)


Nota para la Figura 1 en la página 45:

Nota Descripción

�1� Incluir archivos: esta directriz incluye un archivo en la aplicación fuente.

�2� Sección de declaración: la declaración de variables del lenguaje principal que se

utilizarán para contener valores a los que se hace referencia en las sentencias de

SQL de la aplicación C.

�3� Declaración de variable local: este bloque declara las variables locales a utilizar

en la aplicación. Estas no son variables del lenguaje principal.

�4� Incluyendo la estructura SQLCA: la estructura SQLCA se actualiza tras la

ejecución de cada sentencia de SQL. Esta aplicación de plantilla utiliza

determinados campos de SQLCA para el manejo de errores.

�5� Conexión a una base de datos: el paso inicial al trabajar con la base de datos es

establecer una conexión a la base de datos. Aquí, la conexión se efectúa

ejecutando la sentencia de SQL CONNECT.

�6� Manejo de errores: comprueba si se ha producido un error.

�7� Ejecutar una consulta: la ejecución de esta sentencia de SQL asigna datos

devueltos de una tabla a variables del lenguaje principal. El código C debajo de

la ejecución de la sentencia de SQL imprime los valores de las variables del

lenguaje principal en salida estándar.

/* Leer la fila actualizada mediante STATIC SQL y CURSOR */

EXEC SQL DECLARE posCur1 CURSOR FOR

SELECT id, name, dept, salary



{

printf("Declare Error: SQLCODE = %ld \n", SQLCODE);

}

EXEC SQL OPEN posCur1;

EXEC SQL FETCH posCur1 INTO :id, :name, :dept, :salary ; �9�


{

printf("Fetch Error: SQLCODE = %ld \n", SQLCODE);

}

else

{

printf(" Executing an dynamic SQL statement, updating the

\n salary value for the id equal to 310\n");

printf("\n ID Name DEPT Salary\n");

printf(" %3d %7s %7d %16.2f\n\n", id, name, dept, salary);

}

EXEC SQL CLOSE posCur1;

/* Comprometer la transacción */

printf("\n Commit the transaction.\n");

EXEC SQL COMMIT; �10�


{

printf("Error: SQLCODE = %ld \n", SQLCODE);

}

/* Desconectar de la base de datos */

connect_reset :

EXEC SQL CONNECT RESET; �11�


{

printf("Connection Error: SQLCODE = %ld \n", SQLCODE);

}

return 0;

} /* end main */

Figura 1. Programa de ejemplo: template.sqc (Parte 2 de 2)


Nota Descripción

�8� Ejecutar una operación: la ejecución de esta sentencia de SQL actualiza un

conjunto de filas de una tabla identificada por su número de departamento. La

preparación (realizada tres líneas antes) es un paso en el que los valores de

variables del lenguaje principal, como a la que se hace referencia en esta

sentencia, están enlazadas a la sentencia de SQL que debe ejecutarse.

�9� Ejecutar una operación: en esta línea y en la línea anterior, esta aplicación

utiliza cursores en SQL estático para seleccionar información de una tabla e

imprimir los datos. Una vez se ha declarado y abierto el cursor, se cargan los

datos y, finalmente, se cierra el cursor.

�10� Comprometer la transacción: la sentencia COMMIT finaliza los cambios de la

base de datos que se realizaron dentro de una unidad de trabajo.

�11� Finalmente, la conexión de base de datos debe desactivarse.


v “Recuperación de mensajes de error en aplicaciones de SQL incorporado” en la

página 191


página 150








v “SQLCA (área de comunicaciones SQL)” en Consulta de SQL, Volumen 1

v “Sentencia ROLLBACK” en Consulta de SQL, Volumen 2

v “Sentencia COMMIT” en Consulta de SQL, Volumen 2

Archivos de inclusión y definiciones necesarios para aplicaciones de

SQL incorporado



Los archivos de inclusión son necesarios para proporcionar funciones y tipos

utilizados dentro de la biblioteca. Deben incluirse para que el programa pueda

utilizar las funciones de biblioteca. Por omisión, estos archivos se instalarán en la

carpeta $HOME/sqllib/include. Cada lenguaje principal tiene sus propios métodos

para incluir archivos, así como para utilizar distintas extensiones de archivo.

Dependiendo del lenguaje especificado, deben tomarse ciertas precauciones, como

especificar vías de acceso de archivo.


v “Archivos include para aplicaciones de SQL incorporado C y C++” en la página

48


50


v “Archivos include para aplicaciones de SQL incorporado FORTRAN” en la

página 53

Archivos include para aplicaciones de SQL incorporado C y

C++

Los archivos include específicos del lenguaje principal (archivos de cabecera) para

C y C++ tienen la extensión de archivo .h. Hay dos métodos para incluir archivos:

la sentencia EXEC SQL INCLUDE y la macro #include. El precompilador pasará por

alto #include y sólo procesará los archivos incluidos mediante la sentencia EXEC

SQL INCLUDE. Para localizar los archivos incluidos mediante EXEC SQL INCLUDE, el

precompilador C de DB2 busca en primer lugar en el directorio actual y, a

continuación, en los directorios especificados por la variable de entorno

DB2INCLUDE. Considere los ejemplos siguientes:

v EXEC SQL INCLUDE payroll;

Si el archivo especificado en la sentencia INCLUDE no está encerrado entre

comillas, tal como en el ejemplo anterior, el precompilador C busca payroll.sqc,

y luego payroll.h, en cada uno de los directorios que mira. En los sistemas

operativos UNIX y Linux, el precompilador C++ busca payroll.sqC, luego

payroll.sqx, luego payroll.hpp y luego payroll.h en cada uno de los

directorios que examina. En los sistemas operativos Windows de 32 bits, el

precompilador C++ busca sucesivamente payroll.sqx, payroll.hpp y payroll.h

en cada uno de los directorios que examina.

v EXEC SQL INCLUDE ’pay/payroll.h’;

Si el nombre de archivo está encerrado entre comillas, como en el caso anterior,

no se añade ninguna extensión al nombre.

Si el nombre de archivo entrecomillado no contiene una vía de acceso absoluta,

se utiliza el contenido de DB2INCLUDE para buscar el archivo, y se le añade como

prefijo la vía de acceso especificada en el nombre de archivo de INCLUDE. Por

ejemplo, en los sistemas basados en UNIX y Linux, si DB2INCLUDE se establece en

‘/disk2:myfiles/c’, el precompilador C o C++ busca ‘./pay/payroll.h’, luego

‘/disk2/pay/payroll.h’ y finalmente ‘./myfiles/c/pay/payroll.h’. En los

mensajes del precompilador se muestra la vía de acceso en la que se encuentra

realmente el archivo. En sistemas operativos Windows, sustituya las barras

inclinadas invertidas (\) del ejemplo anterior por barras inclinadas.

Nota: El procesador de línea de mandatos coloca en antememoria el valor de

DB2INCLUDE. Para cambiar el valor de DB2INCLUDE después de haber emitido

mandatos del CLP, entre el mandato TERMINATE, luego vuelva a conectar con

la base de datos y realice una precompilación del modo habitual.

Como ayuda para relacionar los errores del compilador con la fuente original, el

precompilador genera macros #line en el archivo de salida. Esto permite que el

compilador informe de los errores utilizando el nombre de archivo y el número de

línea del archivo fuente o fuente incluido, en lugar del número de línea del archivo

fuente de salida precompilado.

Sin embargo, si se especifica la opción PREPROCESSOR, todas las macros #line

generadas por el precompilador hacen referencia al archivo preprocesado por el

preprocesador C externo. Algunos depuradores y otras herramientas que

relacionan código fuente con código objeto no siempre funcionan bien con la macro

#line. Si la herramienta que desea utilizar se comporta de forma inesperada, utilice

la opción NOLINEMACRO (usada con DB2 PREP) cuando realice la precompilación.

Esta opción evita que se generen macros #line.


A continuación se describen los archivos include destinados a su uso en las

aplicaciones del usuario.

SQLADEF (sqladef.h)

Este archivo contiene prototipos de funciones utilizados por aplicaciones C

y C++ precompiladas.

SQLCA (sqlca.h)

Este archivo define la estructura del Área de comunicaciones de SQL

(SQLCA). El SQLCA contiene variables que utiliza el gestor de bases de

datos para proporcionar a una aplicación información de error sobre la

ejecución de sentencias de SQL y llamadas a API.

SQLCODES (sqlcodes.h)

Este archivo define constantes para el campo SQLCODE de la estructura

SQLCA.

SQLDA (sqlda.h)

Este archivo define la estructura del Área de descriptores de SQL

(SQLDA). La SQLDA se utiliza para pasar datos entre una aplicación y el

gestor de bases de datos.

SQLEXT (sqlext.h)

Este archivo contiene los prototipos y constantes de funciones de aquellas

API de Nivel 1 y Nivel 2 de ODBC que no forman parte de la

especificación de la Interfaz de nivel de llamada de X/Open y, por lo tanto,

se utiliza con permiso de Microsoft Corporation.

SQLE819A (sqle819a.h)

Si la página de códigos de la base de datos es 819 (ISO Latin-1), esta

secuencia clasifica series de caracteres que no son FOR BIT DATA según la

clasificación binaria CCSID 500 (EBCDIC internacional) del sistema

principal. La API CREATE DATABASE utiliza este archivo.

SQLE819B (sqle819b.h)

Si la página de códigos de la base de datos es 819 (ISO Latin-1), esta


clasificación binaria CCSID 037 (EBCDIC inglés de EE.UU.) del sistema



Si la página de códigos de la base de datos es 850 (ASCII Latin-1), esta


clasificación binaria CCSID 500 (EBCDIC internacional) del sistema



Si la página de códigos de la base de datos es 850 (ASCII Latin-1), esta


clasificación binaria CCSID 037 (EBCDIC inglés de EE.UU.) del sistema



Si la página de códigos de la base de datos es 932 (ASCII japonés), esta


clasificación binaria CCSID 5035 (EBCDIC japonés) del sistema principal.

La API CREATE DATABASE utiliza este archivo.


Si la página de códigos de la base de datos es 932 (ASCII japonés), esta



clasificación binaria CCSID 5026 (EBCDIC japonés) del sistema principal.

La API CREATE DATABASE utiliza este archivo.

SQLJACB (sqljacb.h)

Este archivo define constantes, estructuras y bloques de control

correspondientes a la interfaz de DB2 Connect.

SQLSTATE (sqlstate.h)

Este archivo define constantes correspondientes al campo SQLSTATE de la

estructura SQLCA.

SQLSYSTM (sqlsystm.h)

Este archivo contiene definiciones específicas de la plataforma que utilizan

las API y las estructuras de datos del gestor de bases de datos.

SQLUDF (sqludf.h)

Este archivo define constantes y estructuras de interfaces para escribir

funciones definidas por el usuario (UDF).

SQLUV (sqluv.h)

Este archivo define estructuras, constantes y prototipos para la API

asíncrona de Registro de lecturas y para las API utilizadas por los

proveedores de carga y descarga de tablas.


v “Archivos include para las aplicaciones de API de DB2” en Consulta de las API

administrativas



Archivos include para aplicaciones de SQL incorporado

COBOL

Los archivos include específicos del lenguaje principal para COBOL tienen la

extensión de archivo .cbl. Si se utiliza la característica ″Soporte para tipo de datos

de sistema principal System/390″ del compilador COBOL de IBM, los archivos

include de DB2 para las aplicaciones se encuentran en el directorio siguiente:

$HOME/sqllib/include/cobol_i

Si crea los programas de ejemplo de DB2 con los archivos de script suministrados,

deben cambiar la vía de acceso de archivos include especificada en los archivos de

script por el directorio cobol_i, y no por el directorio cobol_a.

Si no utiliza la característica ″Soporte para tipo de datos de sistema principal

System/390″ del compilador COBOL de IBM, o si utiliza una versión anterior de

este compilador, los archivos include de DB2 para las aplicaciones se encuentran en

el directorio siguiente:

$HOME/sqllib/include/cobol_a

Para localizar archivos INCLUDE, el precompilador COBOL de DB2 busca en

primer lugar en el directorio actual y, a continuación, en los directorios

especificados por la variable de entorno DB2INCLUDE. Considere los ejemplos

siguientes:

v EXEC SQL INCLUDE payroll END-EXEC.



comillas, como en el ejemplo anterior, el precompilador C busca payroll.sqb,

luego payroll.cpy y luego payroll.cbl en cada uno de los directorios que mira.

v EXEC SQL INCLUDE ’pay/payroll.cbl’ END-EXEC.


no se añade ninguna extensión al nombre.

Si el nombre del archivo entrecomillado no contiene una vía de acceso absoluta,

se utiliza el contenido de DB2INCLUDE para buscar el archivo, añadiéndole

como prefijo la vía de acceso especificada en el nombre del archivo INCLUDE.

Por ejemplo, con sistemas de bases de datos DB2 para AIX, si DB2INCLUDE se

establece en ‘/disk2:myfiles/cobol’, el precompilador busca

‘./pay/payroll.cbl’, luego ‘/disk2/pay/payroll.cbl’ y finalmente

‘./myfiles/cobol/pay/payroll.cbl’. En los mensajes del precompilador se

muestra la vía de acceso en la que se encuentra realmente el archivo. En las

plataformas Windows, sustituya las barras inclinadas invertidas (\) del ejemplo

anterior por barras inclinadas.

Nota: El procesador de línea de mandatos de DB2 coloca en antememoria el valor

de DB2INCLUDE. Para cambiar el valor de DB2INCLUDE después de haber

emitido mandatos del CLP, entre el mandato TERMINATE, luego vuelva a

conectar con la base de datos y realice una precompilación del modo

habitual.

A continuación se describen los archivos include destinados a su uso en las

aplicaciones del usuario.

SQLCA (sqlca.cbl)

Este archivo define la estructura del Área de comunicaciones de

SQL (SQLCA). El SQLCA contiene variables que utiliza el gestor de

bases de datos para proporcionar a una aplicación información de

error sobre la ejecución de sentencias de SQL y llamadas a API.

SQLCA_92 (sqlca_92.cbl)

Este archivo contiene una versión que se ajusta a FIPS SQL92 Entry

Level de la estructura Área de comunicaciones de SQL (SQL

Communications Area (SQLCA)). Debe incluir este archivo en

lugar del archivo sqlca.cbl cuando escriba aplicaciones DB2 que

se ajusten al estándar FIPS SQL92 Entry Level. El precompilador

de DB2 incluye automáticamente el archivo sqlca_92.cbl cuando

la opción LANGLEVEL del precompilador se establece en SQL92E.

SQLCODES (sqlcodes.cbl)

Este archivo define constantes para el campo SQLCODE de la

estructura SQLCA.

SQLDA (sqlda.cbl)


(SQLDA). La SQLDA se utiliza para pasar datos entre una

aplicación y el gestor de bases de datos.

SQLEAU (sqleau.cbl)

Este archivo contiene definiciones de constantes y de estructuras

necesarias para las API de auditoría de seguridad de DB2. Si

utiliza estas API, tiene que incluir este archivo en el programa. Este

archivo también contiene definiciones de constantes y de valores

de palabras clave para los campos del registro de seguimiento de

auditoría. Programas externos o de extracción de seguimiento de

auditoría de proveedores pueden utilizar estas definiciones.


SQLETSD (sqletsd.cbl)

Este archivo define la estructura Descriptor de espacio de tabla

(Table Space Descriptor), SQLETSDESC, que se pasa a la API para

Crear base de datos, sqlgcrea.

SQLE819A (sqle819a.cbl)

Si la página de códigos de la base de datos es 819 (ISO Latin-1),

esta secuencia clasifica series de caracteres que no son FOR BIT

DATA según la clasificación binaria CCSID 500 (EBCDIC

internacional) del sistema principal. La API CREATE DATABASE

utiliza este archivo.

SQLE819B (sqle819b.cbl)



DATA según la clasificación binaria CCSID 037 (EBCDIC inglés de

EE.UU.) del sistema principal. La API CREATE DATABASE utiliza

este archivo.


Si la página de códigos de la base de datos es 850 (ASCII Latin-1),










este archivo.


Si la página de códigos de la base de datos es 932 (ASCII japonés),


DATA según la clasificación binaria CCSID 5035 (EBCDIC japonés)

del sistema principal. La API CREATE DATABASE utiliza este

archivo.






archivo.

SQL1252A (sql1252a.cbl)

Si la página de códigos de la base de datos es 1252 (Windows

Latin-1), esta secuencia clasifica series de caracteres que no son

FOR BIT DATA según la clasificación binaria CCSID 500 (EBCDIC



SQL1252B (sql1252b.cbl)




inglés de EE.UU.) del sistema principal. La API CREATE

DATABASE utiliza este archivo.


SQLSTATE (sqlstate.cbl)

Este archivo define constantes correspondientes al campo

SQLSTATE de la estructura SQLCA.

SQLUTBCQ (sqlutbcq.cbl)

Este archivo define la estructura de datos (Consulta de contenedor

de espacio de tabla (Table Space Container Query),

SQLB-TBSCONTQRY-DATA, que se utiliza con las API de consulta

del contenedor del espacio de tabla, sqlgstsc, sqlgftcq y sqlgtcq.

SQLUTBSQ (sqlutbsq.cbl)

Este archivo define la estructura de datos Consulta de espacio de

tabla (Table Space Query), SQLB-TBSTQRY-DATA, que se utiliza

con las API de consulta del espacio de tabla, sqlgstsq, sqlgftsq y

sqlgtsq.



administrativas



Archivos include para aplicaciones de SQL incorporado

FORTRAN

Los archivos include específicos del lenguaje principal correspondientes a

FORTRAN tienen la extensión de archivo .f en los sistemas operativos UNIX y

Linux y .for en los sistemas operativos Windows. Existen dos métodos para

incluir archivos: la sentencia EXEC SQL INCLUDE y la sentencia INCLUDE de

FORTRAN. El precompilador pasará por alto las sentencias INCLUDE de

FORTRAN y sólo procesará los archivos incluidos mediante la sentencia EXEC

SQL. Para localizar el archivo INCLUDE, el precompilador FORTRAN de DB2

busca en primer lugar en el directorio actual y, a continuación, en los directorios

especificados por la variable de entorno DB2INCLUDE.

Considere los ejemplos siguientes:

v EXEC SQL INCLUDE payroll


comillas, como en el ejemplo anterior, el precompilador busca sucesivamente

payroll.sqf y payroll.f (payroll.for en sistemas operativos Windows) en cada

uno de los directorios que examina.

v EXEC SQL INCLUDE ’pay/payroll.f’


no se añade ninguna extensión al nombre. (Para sistemas operativos Windows,

el archivo se especificaría como ’pay\payroll.for’.)

Si el nombre de archivo entrecomillado no contiene una vía de acceso absoluta,

se utiliza el contenido de DB2INCLUDE para buscar el archivo, y se le añade

como prefijo la vía de acceso especificada en el nombre de archivo de INCLUDE.

Por ejemplo, en DB2 para los sistemas operativos UNIX y Linux, si

DB2INCLUDE tiene el valor ‘/disk2:myfiles/fortran’, el precompilador busca

sucesivamente ‘./pay/payroll.f’, ‘/disk2/pay/payroll.f’ y finalmente

‘./myfiles/cobol/pay/payroll.f’. En los mensajes del precompilador se muestra

la vía de acceso en la que se encuentra realmente el archivo. En los sistemas


operativos Windows, sustituya las barras inclinadas invertidas (\) por barras

inclinadas y sustituya ‘for’ por la extensión ‘f’ en el ejemplo anterior.

Nota: El procesador de línea de mandatos de DB2 coloca en antememoria el valor

de DB2INCLUDE. Para cambiar el valor de DB2INCLUDE después de haber

emitido mandatos del CLP, entre el mandato TERMINATE, luego vuelva a

conectar con la base de datos y realice una precompilación del modo

habitual.

Los archivos de cabecera FORTRAN de 32 bits necesarios para el desarrollo de

aplicaciones de bases de datos DB2, que antes se encontraban en

$INSTHOME/sqllib/include ahora se encuentran en $INSTHOME/sqllib/include32.

En la Versión 8.1, estos archivos se encontraban en el directorio

$INSTDIR/sqllib/include, que era un enlace simbólico a uno de los directorios

siguientes: $DB2DIR/include o $DB2DIR/include64 según si se trataba de una

instancia de 32 bits o de 64 bits.

En la Versión 9.1, $DB2DIR/include contendrá todos los archivos include (de 32 bits

y de 64 bits) y $DB2DIR/include32 sólo contendrá los archivos FORTRAN de 32 bits

y un archivo README que indicará que los archivos include de 32 bits son los

mismos que los de 64 bits con la excepción de FORTRAN.

El directorio $DB2DIR/include32 sólo existirá en AIX, Solaris, HP-PA y HP-IPF.

Puede utilizar los siguientes archivos include de FORTRAN en las aplicaciones.

SQLCA (sqlca_cn.f, sqlca_cs.f)

Este archivo define la estructura del Área de comunicaciones de

SQL (SQLCA). El SQLCA contiene variables que utiliza el gestor de

bases de datos para proporcionar a una aplicación información de

error sobre la ejecución de sentencias de SQL y llamadas a API.

Se proporcionan dos archivos SQLCA para las aplicaciones

FORTRAN. El valor por omisión, sqlca_cs.f, define la estructura

SQLCA en un formato compatible con SQL de IBM. El archivo

sqlca_cn.f, precompilado con la opción SQLCA NONE, define la

estructura SQLCA para un mejor rendimiento.

SQLCA_92 (sqlca_92.f)

Este archivo contiene una versión que se ajusta a FIPS SQL92 Entry

Level de la estructura Área de comunicaciones de SQL (SQL

Communications Area (SQLCA)). Se debe incluir este archivo en

lugar de los archivos sqlca_cn.f o sqlca_cs.f cuando se escriban

aplicaciones DB2 que se ajusten al estándar FIPS SQL92 Entry

Level. El precompilador de DB2 incluye automáticamente el

archivo sqlca_92.f cuando la opción LANGLEVEL del

precompilador se establece en SQL92E.

SQLCODES (sqlcodes.f)

Este archivo define constantes para el campo SQLCODE de la

estructura SQLCA.

SQLDA (sqldact.f)


(SQLDA). La SQLDA se utiliza para pasar datos entre una

aplicación y el gestor de bases de datos.


SQLEAU (sqleau.f)

Este archivo contiene definiciones de constantes y de estructuras

necesarias para las API de auditoría de seguridad de DB2. Si

utiliza estas API, tiene que incluir este archivo en el programa. Este

archivo también contiene definiciones de constantes y de valores

de palabras clave para los campos del registro de seguimiento de

auditoría. Programas externos o de extracción de seguimiento de

auditoría de proveedores pueden utilizar estas definiciones.

SQLE819A (sqle819a.f)






SQLE819B (sqle819b.f)





este archivo.












este archivo.






archivo.






archivo.

SQL1252A (sql1252a.f)






SQL1252B (sql1252b.f)





inglés de EE.UU.) del sistema principal. La API CREATE

DATABASE utiliza este archivo.

SQLSTATE (sqlstate.f)

Este archivo define constantes correspondientes al campo

SQLSTATE de la estructura SQLCA.






administrativas


Declaración de la SQLCA para el manejo de errores

Puede declarar la SQLCA en el programa de aplicación para que el gestor de bases

de datos pueda devolver información a la aplicación. Cuando preprocesa el

programa, el gestor de bases de datos inserta las declaraciones de variables del

lenguaje principal en lugar de la sentencia INCLUDE. El sistema se comunica con

el programa utilizando las variables para distintivos de aviso, códigos de error e

información de diagnóstico.

Después de ejecutar cada sentencia de SQL, el sistema devuelve un código de

retorno en SQLCODE y en SQLSTATE. SQLCODE es un valor entero que resume

la ejecución de la sentencia y SQLSTATE es un campo de carácter que proporciona

códigos de error comunes entre los productos de bases de datos relacionales de

IBM. SQLSTATE también cumple con los estándares ISO/ANS SQL92 y FIPS 127-2.

Nota: FIPS 127-2 hace referencia a Federal Information Processing Standards

Publication 127-2 for Database Language SQL. ISO/ANS SQL92 hace referencia

a American National Standard Database Language SQL X3.135-1992 e

International Standard ISO/IEC 9075:1992, Database Language SQL.

Observe que si SQLCODE es menor que 0, significa que se ha producido un error

y que la sentencia no se ha procesado. Si SQLCODE es mayor que 0, significa que

se ha emitido un aviso, pero la sentencia se procesa.

Para una aplicación DB2 escrita en C o C++, si la aplicación está formada por

varios archivos fuente, sólo uno de los archivos debería incluir la sentencia EXEC

SQL INCLUDE SQLCA para evitar varias definiciones de SQLCA. El resto de los

archivos fuente deberían utilizar las siguientes líneas:

#include "sqlca.h"

extern struct sqlca sqlca;

Procedimiento:

Para declarar la SQLCA, codifique la sentencia INCLUDE SQLCA en el programa del

siguiente modo:

v Para aplicaciones C o C++ utilice:

EXEC SQL INCLUDE SQLCA;


v En aplicaciones Java no se utiliza de forma explícita la SQLCA. Utilice en su

lugar los métodos de instancia SQLException para obtener los valores de

SQLSTATE y SQLCODE.

v Para aplicaciones COBOL utilice:

EXEC SQL INCLUDE SQLCA END-EXEC.

v Para aplicaciones FORTRAN utilice:

EXEC SQL INCLUDE SQLCA

Si la aplicación debe cumplir con el estándar ISO/ANS SQL92 o FIPS 127-2, no

utilice las sentencias anteriores ni la sentencia INCLUDE SQLCA.


v “Manejo de errores utilizando la sentencia WHENEVER” en la página 57

v “Variables SQLSTATE y SQLCODE en una aplicación de SQL incorporado C y


v “Variables SQLSTATE y SQLCODE en aplicaciones de SQL incorporado COBOL”

en la página 122

v “Variables SQLSTATE y SQLCODE en aplicaciones de SQL incorporado


v “Las variables SQLSTATE y SQLCODE en Perl” en Desarrollo de aplicaciones Perl

y PHP

Manejo de errores utilizando la sentencia WHENEVER

La sentencia WHENEVER hace que el precompilador genere código fuente que

indica a la aplicación que vaya a una etiqueta especificada si se produce un error,

un aviso o si no se encuentran filas durante la ejecución. La sentencia WHENEVER

afecta a las siguientes sentencias de SQL ejecutables hasta que otra sentencia

WHENEVER altera la situación.

La sentencia WHENEVER tiene tres formatos básicos:

EXEC SQL WHENEVER SQLERROR acción

EXEC SQL WHENEVER SQLWARNING acción

EXEC SQL WHENEVER NOT FOUND acción

En las sentencias anteriores:

SQLERROR

Identifica cualquier condición en la que SQLCODE < 0.

SQLWARNING

Identifica cualquier condición en la que SQLWARN(0) = W o SQLCODE > 0

pero no es igual a 100.

NOT FOUND

Identifica cualquier condición en la que SQLCODE = 100.

En cada caso, acción puede ser cualquiera de las siguientes:

CONTINUE

Indica que hay que continuar con la siguiente instrucción de la aplicación.

GO TO etiqueta

Indica que hay que ir a la sentencia que va inmediatamente detrás de la

etiqueta especificada después de GO TO. (GO TO puede especificarse

como dos palabras o como una sola, GOTO.)


Si no se utiliza la sentencia WHENEVER, la acción por omisión consiste en

continuar el proceso si se produce una condición de error, de aviso o de excepción

durante la ejecución.

La sentencia WHENEVER debe aparecer antes de las sentencias de SQL que desea

que se vean afectadas. De lo contrario, el precompilador no sabe que se debe

generar código de manejo de errores adicional para las sentencias de SQL

ejecutables. En un momento cualquiera puede estar activa una combinación

cualquiera de los tres formatos básicos. El orden en el que declare los tres formatos

no es significativo.

Para evitar una situación de bucle infinito, asegúrese de deshacer el manejo

WHENEVER antes de que se ejecute alguna sentencia de SQL dentro del

manejador. Puede hacerlo utilizando la sentencia WHENEVER SQLERROR

CONTINUE.


v “Sentencia WHENEVER” en Consulta de SQL, Volumen 2

Conexión con bases de datos DB2 en aplicaciones de SQL

incorporado

Para poder trabajar con una base de datos, tiene que establecer una conexión con

dicha base de datos. SQL incorporado proporciona varias formas que le permiten

incluir código para establecer conexiones de base de datos. En función del lenguaje

de programación principal de SQL incorporado, puede haber una o varias formas

de hacerlo.

Las conexiones de base de datos se pueden establecer de forma implícita o

explícita. Una conexión implícita es una conexión en la que se supone que el ID de

usuario es el ID de usuario actual. Este tipo de conexión no se recomienda para

aplicaciones de bases de datos. Se recomienda utilizar conexiones de bases de

datos explícitas, que necesitan que se especifique un ID de usuario y una

contraseña.

Conexión con bases de datos DB2 en aplicaciones de SQL incorporado C y C++:

Cuando se trabaja con aplicaciones C y C++, se puede establecer una conexión de

base de datos ejecutando la siguiente sentencia.

EXEC SQL CONNECT TO sample;

Si desea utilizar un id de usuario (herrick) y una contraseña (mypassword)

específicos, utilice la siguiente sentencia:

EXEC SQL CONNECT TO sample USER herrick USING mypassword;

Conexión con bases de datos DB2 en aplicaciones de SQL incorporado COBOL:

Cuando se trabaja con aplicaciones COBOL, se establece una conexión de base de

datos ejecutando la siguiente sentencia. Esta sentencia crea una conexión con la

base de datos sample utilizando el nombre de usuario por omisión.

EXEC SQL CONNECT TO sample END-EXEC.




EXEC SQL CONNECT TO sample USER herrick USING mypassword END-EXEC.

Conexión con bases de datos DB2 en aplicaciones de SQL incorporado

FORTRAN:

Cuando se trabaja con aplicaciones FORTRAN, se establece una conexión de base

de datos ejecutando la siguiente sentencia. Esta sentencia crea una conexión con la


EXEC SQL CONNECT TO sample



EXEC SQL CONNECT TO sample USER herrick USING mypassword

Conexión con bases de datos DB2 en aplicaciones de SQL incorporado REXX:

Cuando se trabaja con aplicaciones REXX, se establece una conexión de base de

datos ejecutando la siguiente sentencia. Esta sentencia crea una conexión con la


CALL SQLEXEC ’CONNECT TO sample’



CALL SQLEXEC ’CONNECT TO sample USER herrick USING mypassword’



página 150


v “Sentencia CONNECT (Tipo 1)” en Consulta de SQL, Volumen 2


v “Sentencia EXECUTE” en Consulta de SQL, Volumen 2

Tipos de datos que se correlacionan con tipos de datos SQL en


Tipos de datos que se correlacionan con tipos de datos SQL


Para intercambiar datos entre una aplicación y la base de datos, utilice las

correlaciones de tipos de datos correctas para las variables utilizadas.Cuando el

precompilador encuentra una declaración de una variable del lenguaje principal,

determina el valor del tipo de SQL apropiado. Con cada lenguaje principal hay

reglas de correlación especiales a las que hay que ceñirse, exclusivas para ese

lenguaje específico.



en la página 72








Tipos de datos de SQL soportados en aplicaciones de SQL

incorporado C y C++


incorporado C y C++

Ciertos tipos de datos predefinidos de C y C++ corresponden a los tipos de

columna de base de datos de DB2. Sólo se pueden declarar como variables del

lenguaje principal estos tipos de datos de C y C++.

Las tablas siguientes muestran el equivalente en C y C++ de cada tipo de columna.

Cuando el precompilador encuentra una declaración de una variable del lenguaje

principal, determina el valor del tipo de SQL apropiado. El gestor de bases de

datos utiliza este valor para convertir los datos intercambiados entre la aplicación y

él mismo.

Tabla 2. Tipos de datos de SQL correlacionados con declaraciones de C y C++

Tipo de columna SQL1 Tipo de datos de C y C++ Descripción del tipo de columna SQL

SMALLINT

(500 ó 501)

short

short int

sqlint16

Entero con signo de 16 bits

INTEGER

(496 ó 497)

long

long int

sqlint322


BIGINT

(492 ó 493)

long long

long

__int64

sqlint643


REAL4

(480 ó 481)

float Coma flotante de precisión simple

DOUBLE5

(480 ó 481)

double Coma flotante de precisión doble

DECIMAL(p,s)

(484 ó 485)

No existe un equivalente exacto;

utilice double

Decimal empaquetado

(Considere la posibilidad de utilizar las

funciones CHAR y DECIMAL para

manipular los campos decimales

empaquetados como datos de tipo carácter.)

CHAR(1)

(452 ó 453)

char Carácter simple

CHAR(n)

(452 ó 453)


utilice char[n+1], donde n es

suficientemente grande para

contener los datos

1<=n<=254

Serie de caracteres de longitud fija


Tabla 2. Tipos de datos de SQL correlacionados con declaraciones de C y C++ (continuación)


VARCHAR(n)

(448 ó 449)

struct tag {

short int;

char[n]

}

1<=n<=32 672

Serie de caracteres de longitud variable no

terminada en nulo con indicador de longitud

de serie de 2 bytes

Como alternativa, utilice

char[n+1], donde n es


contener los datos

1<=n<=32 672

Serie de caracteres de longitud variable

terminada en nulo

Nota: Se le asigna un tipo SQL de 460/461.

LONG VARCHAR

(456 ó 457)

struct tag {

short int;

char[n]

}

32 673<=n<=32 700



de serie de 2 bytes

CLOB(n)

(408 ó 409)

sql type is

clob(n)

1<=n<=2 147 483 647



de serie de 4 bytes

Variable de localizador

CLOB6

(964 ó 965)

sql type is

clob_locator

Identifica las entidades CLOB que residen en

el servidor

Variable de referencia de

archivo CLOB6

(920 ó 921)

sql type is

clob_file

Descriptor del archivo que contiene datos

CLOB

BLOB(n)

(404 ó 405)

sql type is

blob(n)

1<=n<=2 147 483 647

Serie binaria variable no terminada en nulo

con indicador de longitud de serie de 4 bytes


BLOB6

(960 ó 961)

sql type is

blob_locator

Identifica las entidades BLOB del servidor


archivo BLOB6

(916 ó 917)

sql type is

blob_file


BLOB

DATE

(384 ó 385)

Formato de caracteres terminado

en nulo

Admitir como mínimo 11 caracteres para

acomodar el terminador nulo

Formato estructurado VARCHAR Admitir como mínimo 10 caracteres

TIME

(388 ó 389)


en nulo




TIMESTAMP

(392 ó 393)


en nulo







XML7

(988 ó 989)

struct {

sqluint32 length;

char data[n];

}

1<=n<=2 147 483 647

SQLUDF_CLOB

Valor XML

Los tipos de datos siguientes sólo están disponibles en los entornos DBCS o EUC si

se compilan previamente con la opción WCHARTYPE NOCONVERT.



GRAPHIC(1)

(468 ó 469)

sqldbchar Carácter simple de doble byte

GRAPHIC(n)

(468 ó 469)


utilice sqldbchar[n+1], donde n es


contener los datos

1<=n<=127

Serie de caracteres de doble byte y longitud

fija

VARGRAPHIC(n)

(464 ó 465)

struct tag {

short int;

sqldbchar[n]

}

1<=n<=16 336


variable no terminada en nulo con indicador

de longitud de serie de 2 bytes


sqldbchar[n+1], donde n es


contener los datos

1<=n<=16 336


variable terminada en nulo


LONG VARGRAPHIC

(472 ó 473)

struct tag {

short int;

sqldbchar[n]

}

16 337<=n<=16 350




Los tipos de datos siguientes sólo están disponibles en los entornos DBCS o EUC si

se compilan previamente con la opción WCHARTYPE CONVERT.



GRAPHIC(1)

(468 ó 469)

wchar_t v Carácter amplio simple (para tipo C)

v Carácter de doble byte simple (para tipo de

columna)




GRAPHIC(n)

(468 ó 469)


utilice wchar_t [n+1], donde n es


contener los datos

1<=n<=127


fija

VARGRAPHIC(n)

(464 ó 465)

struct tag {

short int;

wchar_t [n]

}

1<=n<=16 336





char[n+1], donde n es


contener los datos

1<=n<=16 336




LONG VARGRAPHIC

(472 ó 473)

struct tag {

short int;

wchar_t [n]

}

16 337<=n<=16 350




Los tipos de datos siguientes sólo están disponibles en los entornos DBCS o EUC.



DBCLOB(n)

(412 ó 413)

sql type is

dbclob(n)

1<=n<=1 073 741 823





DBCLOB6

(968 ó 969)

sql type is

dbclob_locator

Identifica las entidades DBCLOB que residen

en el servidor


archivos

DBCLOB6

(924 ó 925)

sql type is

dbclob_file


DBCLOB




Notas:

1. El primer número que se encuentra bajo Tipo de columna SQL indica que no se proporciona una variable de

indicador, y el segundo número indica que se proporciona una variable de indicador. Se necesita una variable de

indicador para indicar los valores nulos (NULL) o para contener la longitud de una serie truncada. Éstos son los

valores que aparecerán en el campo SQLTYPE de la SQLDA para estos tipos de datos.

2. Por razones de compatibilidad entre plataformas, utilice sqlint32. En los sistemas operativos UNIX y Linux de 64

bits, ″long″ es un entero de 64 bits. En los sistemas operativos Windows de 64 bits y UNIX y Linux de 32 bits,

″long″ es un entero de 32 bits.

3. Por razones de compatibilidad entre plataformas, utilice sqlint64. El archivo de cabecera sqlsystm.h del sistema de

bases de datos DB2 definirá el tipo de sqlint64 como ″__int64″ en los sistemas operativos Windows soportados

cuando se utilice el compilador de Microsoft, como ″long long″ en los sistemas operativos UNIX y Linux de 32

bits y como ″long″ en los sistemas operativos UNIX y Linux de 64 bits.

4. FLOAT(n) donde 0 < n < 25 es un sinónimo de REAL. La diferencia entre REAL y DOUBLE en la SQLDA es el

valor de la longitud (4 u 8).

5. Los tipos SQL siguientes son sinónimos de DOUBLE:

v FLOAT

v FLOAT(n) donde 24 < n < 54 es un sinónimo de DOUBLE

v DOUBLE PRECISION

6. Éste no es un tipo de columna, sino un tipo de variable del lenguaje principal.

7. El valor SQL_TYP_XML/SQL_TYP_NXML sólo se devuelve por parte de peticiones DESCRIBE. No se puede

utilizar directamente por parte de la aplicación para vincular recursos de aplicaciones con valores XML.

A continuación mostramos normas adicionales para los tipos de datos C y C++

soportados:

v El tipo de datos char se puede declarar como char o unsigned char.

v El gestor de bases de datos procesa los datos de serie de caracteres de longitud

variable y terminados en nulo del tipo char[n] (tipo de datos 460) como

VARCHAR(m).

– Si LANGLEVEL es SAA1, la longitud de la variable del lenguaje principal m

es igual a la longitud de la serie de caracteres n en char[n] o al número de

bytes que preceden al primer terminador nulo ( \0), el valor más bajo de

ambos.

– Si LANGLEVEL es MIA, la longitud de la variable del lenguaje principal m es

igual al número de bytes que preceden al primer terminador nulo (\0).v El gestor de bases de datos procesa el tipo de datos de serie de caracteres de

gráficos y longitud variable terminados en nulo, wchar_t[n] o sqldbchar[n]

(tipo de datos 400), como VARGRAPHIC(m).

– Si LANGLEVEL es SAA1, la longitud de la variable del lenguaje principal m

es igual a la longitud de la serie de caracteres n en wchar_t[n] o

sqldbchar[n], o al número de caracteres que preceden al primer terminador

nulo de gráficos, el valor más pequeño de ambos.

– Si LANGLEVEL es MIA, la longitud de la variable del lenguaje principal m es

igual al número de caracteres que preceden al primer terminador nulo de

gráficos.v No se soportan los tipos de datos numéricos sin signo.

v El tipo de datos int de C y C++ no está permitido, puesto que su representación

interna depende de la máquina.






en la página 86






v “Ejemplos de C++” en Temas de ejemplos


Tipos de datos para procedimientos, funciones y métodos en

aplicaciones de SQL incorporado C y C++

La tabla siguiente lista las correlaciones soportadas entre tipos de datos de SQL y

tipos de datos de C y C++ para procedimientos, UDF y métodos.


Tipo de columna SQL1 Tipo de datos de C y C++ Descripción del tipo de columna de SQL

SMALLINT

(500 ó 501)

short Entero con signo de 16 bits

INTEGER

(496 ó 497)

sqlint32 Entero con signo de 32 bits

BIGINT

(492 ó 493)

sqlint64 entero con signo de 64 bits

REAL

(480 ó 481)

float Coma flotante de precisión simple

DOUBLE

(480 ó 481)

double Coma flotante de precisión doble

DECIMAL(p,s)

(484 ó 485)

No soportado Para pasar un valor decimal, defina el parámetro

como tipo de datos convertible desde DECIMAL

(por ejemplo, CHAR o DOUBLE) y convierta

explícitamente el argumento a este tipo.

CHAR(n)

(452 ó 453)

char[n+1] donde n es suficientemente

grande para contener los datos

1<=n<=254

Serie de caracteres de longitud fija terminada en

nulo

CHAR(n) FOR BIT DATA

(452 ó 453)



1<=n<=254

Serie de caracteres de longitud fija

VARCHAR(n)

(448 ó 449) (460 ó 461)



1<=n<=32 672

Serie de longitud variable terminada en nulo

VARCHAR(n) FOR BIT DATA

(448 ó 449)

struct {

sqluint16 length;

char[n]

}

1<=n<=32 672


terminada en nulo




LONG VARCHAR

(456 ó 457)

struct {

sqluint16 length;

char[n]

}

32 673<=n<=32 700


terminada en nulo

CLOB(n)

(408 ó 409)

struct {

sqluint32 length;

char data[n];

}

1<=n<=2 147 483 647


terminada en nulo con indicador de longitud de

serie de 4 bytes

BLOB(n)

(404 ó 405)

struct {

sqluint32 length;

char data[n];

}

1<=n<=2 147 483 647

Serie binaria de longitud variable no terminada en

nulo con indicador de longitud de serie de 4 bytes

DATE

(384 ó 385)

char[11] Formato de caracteres terminado en nulo

TIME

(388 ó 389)


TIMESTAMP

(392 ó 393)


XML

(988/989)

No soportado Este valor de tipo de descriptor (988/989) se

definirá para que se utilice en la SQLDA para

describir y para indicar datos XML (en su formato

serializado). Los tipos de caracteres y binarios

existentes (incluidos los LOB y los tipos de

referencia de archivos LOB) también se pueden

utilizar para captar e insertar los datos (sólo SQL

dinámico)

Nota: Los tipos de datos siguientes sólo están disponibles en los entornos DBCS o

EUC si se compilan previamente con la opción WCHARTYPE

NOCONVERT.



GRAPHIC(n)

(468 ó 469)

sqldbchar[n+1] donde n es

suficientemente grande para contener

los datos

1<=n<=127

Serie de caracteres de doble byte y longitud fija

terminada en nulo

VARGRAPHIC(n)

(400 ó 401)

sqldbchar[n+1] donde n es


los datos

1<=n<=16 336


variable no terminada en nulo

LONG VARGRAPHIC

(472 ó 473)

struct {

sqluint16 length;

sqldbchar[n]

}

16 337<=n<=16 350






DBCLOB(n)

(412 ó 413)

struct {

sqluint32 length;

sqldbchar data[n];

}

1<=n<=1 073 741 823



serie de 4 bytes

Notas:

1. El primer número que se encuentra bajo Tipo de columna SQL indica que no se proporciona una variable de indicador, y el

segundo número indica que se proporciona una variable de indicador. Es necesaria una variable de indicador para indicar los

valores NULL o para que contenga la longitud de una serie truncada. Éstos son los valores que aparecerían en el campo

SQLTYPE de la SQLDA para estos tipos de datos.


v “Variables de indicador de nulo o de truncamiento y tablas de indicadores en


v “Llamada a procedimientos almacenados en aplicaciones de SQL incorporado C

y C++” en la página 171


incorporado COBOL

Ciertos tipos de datos de COBOL predefinidos corresponden a tipos de columna

de base de datos DB2. Sólo estos tipos de datos de COBOL se pueden declarar

como variables del lenguaje principal.

La tabla siguiente muestra el equivalente en COBOL de cada tipo de columna.

Cuando el precompilador encuentra una declaración de variable del lenguaje

principal, determina el valor del tipo de SQL adecuado. El gestor de bases de datos

utiliza este valor para convertir los datos intercambiados entre la aplicación y él

mismo.

No se reconoce cada descripción de datos posible para las variables del lenguaje

principal. Los elementos de datos de COBOL deben ser coherentes con los

descritos en la tabla siguiente. Si utiliza otros elementos de datos, se puede

producir un error.

Tabla 8. Tipos de datos de SQL correlacionados con declaraciones de COBOL

Tipo de columna de SQL1 Tipo de datos de COBOL

Descripción del tipo de

columna de SQL

SMALLINT

(500 ó 501)

01 name PIC S9(4) COMP-5. Entero con signo de 16 bits

INTEGER

(496 ó 497)


BIGINT

(492 ó 493)


DECIMAL(p,s)

(484 ó 485)

01 name PIC S9(m)V9(n) COMP-3. Decimal empaquetado

REAL2

(480 ó 481)

01 name USAGE IS COMP-1. Coma flotante de precisión

simple

DOUBLE3

(480 ó 481)

01 name USAGE IS COMP-2. Coma flotante de precisión

doble

CHAR(n)

(452 ó 453)

01 name PIC X(n). Serie de caracteres de longitud

fija


Tabla 8. Tipos de datos de SQL correlacionados con declaraciones de COBOL (continuación)



columna de SQL

VARCHAR(n)

(448 ó 449)

01 name.

49 length PIC S9(4) COMP-5.

49 name PIC X(n).

1<=n<=32 672

Serie de caracteres de longitud

variable

LONG VARCHAR

(456 ó 457)

01 name.


49 data PIC X(n).

32 673<=n<=32 700


variable larga

CLOB(n)

(408 ó 409)

01 MY-CLOB USAGE IS SQL TYPE IS CLOB(n).

1<=n<=2 147 483 647


variable y objeto grande

Variable de localizador de

CLOB4

(964 ó 965)

01 MY-CLOB-LOCATOR USAGE IS SQL TYPE IS

CLOB-LOCATOR.

Identifica entidades CLOB que

residen en el servidor

Variable de referencia a archivos

CLOB4

(920 ó 921)

01 MY-CLOB-FILE USAGE IS SQL TYPE IS CLOB-FILE. Descriptor de un archivo que

contiene datos CLOB

BLOB(n)

(404 ó 405)

01 MY-BLOB USAGE IS SQL TYPE IS BLOB(n).

1<=n<=2 147 483 647

Serie binaria de longitud

variable y objeto grande


BLOB4

(960 ó 961)

01 MY-BLOB-LOCATOR USAGE IS SQL TYPE IS

BLOB-LOCATOR.

Identifica entidades BLOB que



BLOB4

(916 ó 917)

01 MY-BLOB-FILE USAGE IS SQL TYPE IS BLOB-FILE. Descriptor del archivo que

contiene datos BLOB

DATE

(384 ó 385)

01 identifier PIC X(10). Serie de caracteres de 10 bytes

TIME

(388 ó 389)


TIMESTAMP

(392 ó 393)


XML5

(988 ó 989)

01 name USAGE IS SQL TYPE IS XML AS CLOB ( size ). Valor XML

Los tipos de datos siguientes sólo están disponibles en el entorno DBCS.

Tabla 9. Tipos de datos de SQL correlacionados con declaraciones de COBOL



columna de SQL

GRAPHIC(n)

(468 ó 469)

01 name PIC G(n) DISPLAY-1. Serie de caracteres de doble

byte de longitud fija

VARGRAPHIC(n)

(464 ó 465)

01 name.


49 name PIC G(n) DISPLAY-1.

1<=n<=16 336

Serie de caracteres de doble

byte de longitud variable con

indicador de longitud de serie

de 2 bytes


Tabla 9. Tipos de datos de SQL correlacionados con declaraciones de COBOL (continuación)



columna de SQL

LONG VARGRAPHIC

(472 ó 473)

01 name.


49 name PIC G(n) DISPLAY-1.

16 337<=n<=16 350


byte de longitud variable con

indicador de longitud de serie

de 2 bytes

DBCLOB(n)

(412 ó 413)

01 MY-DBCLOB USAGE IS SQL TYPE IS DBCLOB(n).

1<=n<=1 073 741 823


byte de longitud variable y de

objeto grande con indicador

de longitud de serie de 4

bytes


DBCLOB4

(968 ó 969)

01 MY-DBCLOB-LOCATOR USAGE IS SQL TYPE IS

DBCLOB-LOCATOR.

Identifica entidades DBCLOB

que residen en el servidor


DBCLOB4

(924 ó 925)

01 MY-DBCLOB-FILE USAGE IS SQL TYPE IS

DBCLOB-FILE.

Descriptor de un archivo que

contiene datos DBCLOB

Notas:

1. El primer número debajo de Tipo de columna de SQL indica que no se proporciona una variable de indicador, y el segundo

número indica que sí se proporciona dicha variable. Es necesaria una variable de indicador para indicar los valores NULL o para

que contenga la longitud de una serie truncada. Éstos son los valores que aparecerían en el campo SQLTYPE de la SQLDA para

estos tipos de datos.

2. FLOAT(n) donde 0 < n < 25 es un sinónimo de REAL. La diferencia entre REAL y DOUBLE en la SQLDA es el valor de la

longitud (4 u 8).

3. Los tipos de SQL siguientes son sinónimos de DOUBLE:

v FLOAT

v FLOAT(n) donde 24 < n < 54 es sinónimo de DOUBLE.

v DOUBLE PRECISION

4. No es un tipo de columna, sino un tipo de variable del lenguaje principal.

5. El valor SQL_TYP_XML/SQL_TYP_NXML sólo se devuelve por parte de peticiones DESCRIBE. No se puede utilizar

directamente por parte de la aplicación para vincular recursos de aplicaciones con valores XML.

A continuación, se facilitan reglas adicionales para los tipos de datos de COBOL

soportados:

v PIC S9 y COMP-3/COMP-5 son necesarios donde se muestran.

v Se puede utilizar el número de nivel 77 en lugar del 01 para todos los tipos de

columna, excepto VARCHAR, LONG VARCHAR, VARGRAPHIC, LONG

VARGRAPHIC y todos los tipos de variable de LOB.

v Utilice las reglas siguientes al declarar variables del lenguaje principal para los

tipos de columna DECIMAL(p,s). Vea el ejemplo siguiente:

01 identifier PIC S9(m)V9(n) COMP-3

– Utilice V para indicar la coma decimal.

– Los valores para n y m deben ser superiores o equivalentes a 1.

– El valor de n + m no puede ser superior a 31.

– El valor para s equivale al valor para n.

– El valor para p equivale al valor de n + m.

– Los factores de repetición (n) y (m) son opcionales. Todos los ejemplos

siguientes resultan válidos:

01 identifier PIC S9(3)V COMP-3

01 identifier PIC SV9(3) COMP-3

01 identifier PIC S9V COMP-3

01 identifier PIC SV9 COMP-3

– Se puede utilizar PACKED-DECIMAL en lugar de COMP-3.v Las matrices no están soportadas por el precompilador de COBOL.




incorporado COBOL” en la página 120





v “Nombres de variables del lenguaje principal en COBOL” en la página 119







página 166




incorporado FORTRAN

Ciertos tipos de datos de FORTRAN predefinidos corresponden a tipos de columna

de base de datos DB2. Sólo se pueden declarar como variables del lenguaje

principal estos tipos de datos de FORTRAN.

La tabla siguiente muestra el equivalente en FORTRAN de cada tipo de columna.

Cuando el precompilador encuentra una declaración de una variable del lenguaje

principal, determina el valor del tipo de SQL apropiado. El gestor de bases de

datos utiliza este valor para convertir los datos intercambiados entre la aplicación y

él mismo.

Tabla 10. Tipos de datos SQL correlacionados con declaraciones FORTRAN

Tipo de columna SQL1 Tipo de datos FORTRAN Descripción del tipo de columna SQL

SMALLINT

(500 ó 501)

INTEGER*2 Entero con signo de 16 bits

INTEGER

(496 ó 497)

INTEGER*4 Entero con signo de 32 bits

REAL2

(480 ó 481)

REAL*4 Coma flotante de precisión simple

DOUBLE3

(480 ó 481)

REAL*8 Coma flotante de precisión doble

DECIMAL(p,s)

(484 ó 485)


utilice REAL*8

Decimal empaquetado

CHAR(n)

(452 ó 453)

CHARACTER*n Serie de caracteres de longitud fija con longitud n,

donde n va de 1 a 254

VARCHAR(n)

(448 ó 449)

SQL TYPE IS VARCHAR(n), donde n

va de 1 a 32 672

Serie de caracteres de longitud variable

LONG VARCHAR

(456 ó 457)

SQL TYPE IS VARCHAR(n), donde n

va de 32 673 a 32 700

Serie de caracteres de longitud variable larga

CLOB(n)

(408 ó 409)

SQL TYPE IS CLOB (n) donde n va de

1 a 2 147 483 647

Serie de caracteres de longitud variable y objeto

grande


Tabla 10. Tipos de datos SQL correlacionados con declaraciones FORTRAN (continuación)

Tipo de columna SQL1 Tipo de datos FORTRAN Descripción del tipo de columna SQL


CLOB4

(964 ó 965)

SQL TYPE IS CLOB_LOCATOR Identifica las entidades CLOB que residen en el

servidor


archivo CLOB4

(920 ó 921)

SQL TYPE IS CLOB_FILE Descriptor de archivo que contiene datos CLOB

BLOB(n)

(404 ó 405)

SQL TYPE IS BLOB (n) donde n va de

1 a 2 147 483 647

Serie binaria de longitud variable y objeto grande

Variable de

localizador BLOB4

(960 ó 961)

SQL TYPE IS BLOB_LOCATOR Identifica las entidades BLOB del servidor


archivo BLOB4

(916 ó 917)

SQL TYPE IS BLOB_FILE Descriptor del archivo que contiene datos BLOB

DATE

(384 ó 385)

CHARACTER*10 Serie de caracteres de 10 bytes

TIME

(388 ó 389)


TIMESTAMP

(392 ó 393)


XML

(988 ó 989)

SQL_TYP_XML No hay soporte de XML para FORTRAN; las

aplicaciones pueden obtener el tipo de descripción,

pero no pueden utilizarlo.

Notas:


segundo número indica que se proporciona una variable de indicador. Se necesita una variable de indicador para indicar los

valores nulos (NULL) o para contener la longitud de una serie truncada. Éstos son los valores que aparecerán en el campo

SQLTYPE de la SQLDA para estos tipos de datos.


longitud (4 u 8).


v FLOAT


v DOUBLE PRECISION


A continuación mostramos una norma adicional para los tipos de datos FORTRAN

soportados:

v Puede definir sentencias de SQL dinámicas que contengan más de 254 caracteres

utilizando las variables del lenguaje principal VARCHAR, LONG VARCHAR o

CLOB.















incorporado REXX

Ciertos tipos de datos de REXX predefinidos corresponden a tipos de columna de

base de datos DB2. Sólo se pueden declarar como variables del lenguaje principal

estos tipos de datos de REXX. La tabla siguiente muestra cómo SQLEXEC y

SQLDBS interpretan variables de REXX para convertir su contenido en tipos de

datos de DB2.

Tabla 11. Tipos de columna de SQL correlacionados con declaraciones de REXX

Tipo de columna SQL1 Tipo de datos de REXX Descripción del tipo de columna SQL

SMALLINT

(500 ó 501)

Un número sin coma decimal que va de -32 768

a 32 767


INTEGER

(496 ó 497)

Un número sin coma decimal que va de

-2 147 483 648 a 2 147 483 647


REAL2

(480 ó 481)

Un número en notación científica que va de

-3.40282346 x 1038 a 3.40282346 x 1038

Coma flotante de precisión única

DOUBLE3

(480 ó 481)

Un número en notación científica que va de

-1.79769313 x 10308 a 1.79769313 x 10308

Coma flotante de precisión doble

DECIMAL(p,s)

(484 ó 485)

Un número con una coma decimal Decimal empaquetado

CHAR(n)

(452 ó 453)

Una serie con una comilla inicial y otra final (’),

cuya longitud es n después de eliminar las dos

comillas

Una serie de longitud n sin ningún carácter no

numérico, aparte de los blancos inicial y final o

la E en notación científica

Serie de caracteres de longitud fija con longitud

n, donde n va de 1 a 254

VARCHAR(n)

(448 ó 449)

Equivalente a CHAR(n) Serie de caracteres de longitud variable con

longitud n, donde n va de 1 a 4000

LONG VARCHAR

(456 ó 457)

Equivalente a CHAR(n) Serie de caracteres de longitud variable con

longitud n, donde n va de 1 a 32 700

CLOB(n)

(408 ó 409)

Equivalente a CHAR(n) Serie de caracteres de longitud variable y de

objeto grande con longitud n, donde n va de 1 a

2 147 483 647


CLOB4

(964 ó 965)

DECLARE :nombre_var LANGUAGE TYPE

CLOB LOCATOR

Identifica las entidades CLOB que residen en el

servidor


archivo CLOB4

(920 ó 921)


CLOB FILE

Descriptor de archivo que contiene datos CLOB

BLOB(n)

(404 ó 405)

Una serie con un apóstrofo inicial y uno final,

precedida de BIN, que contiene n caracteres

después de eliminar el BIN precedente y los dos

apóstrofos.

Serie binaria de longitud variable y de objeto

grande con longitud n, donde n va de 1 a

2 147 483 647


BLOB4

(960 ó 961)


BLOB LOCATOR

Identifica las entidades BLOB del servidor


archivo BLOB4

(916 ó 917)


BLOB FILE

Descriptor del archivo que contiene datos BLOB

DATE

(384 ó 385)

Equivalente a CHAR(10) Serie de caracteres de 10 bytes


Tabla 11. Tipos de columna de SQL correlacionados con declaraciones de REXX (continuación)


TIME

(388 ó 389)


TIMESTAMP

(392 ó 393)


XML

(988 ó 989)

SQL_TYP_XML No hay soporte de XML para REXX; las

aplicaciones pueden obtener el tipo de

descripción, pero no pueden utilizarlo.

Los tipos de datos siguientes sólo están disponibles en el entorno DBCS.

Tabla 12. Tipos de columna de SQL correlacionados con declaraciones de REXX


GRAPHIC(n)

(468 ó 469)

Una serie con un apóstrofo inicial y uno

final, precedida de una G o una N, que

contiene n caracteres DBCS después de

eliminar el carácter precedente y los dos

apóstrofos

Serie gráfica de longitud fija con longitud

n, donde n va de 1 a 127

VARGRAPHIC(n)

(464 ó 465)

Equivalente a GRAPHIC(n) Serie gráfica de longitud variable con

longitud n, donde n va de 1 a 2000

LONG VARGRAPHIC

(472 ó 473)

Equivalente a GRAPHIC(n) Serie gráfica de longitud variable larga con

longitud n, donde n va de 1 a 16 350

DBCLOB(n)

(412 ó 413)

Equivalente a GRAPHIC(n) Serie gráfica de longitud variable y de

objeto grande con longitud n, donde n va

de 1 a 1 073 741 823


DBCLOB4

(968 ó 969)


DBCLOB LOCATOR

Identifica las entidades DBCLOB que



archivos DBCLOB4

(924 ó 925)


DBCLOB FILE

Descriptor de archivo que contiene datos

DBCLOB

Notas:


segundo número indica que se proporciona una variable de indicador. Se necesita una variable de indicador para indicar los

valores nulos (NULL) o para contener la longitud de una serie truncada.


longitud (4 u 8).


v FLOAT


v DOUBLE PRECISION




incorporado REXX” en la página 149



v “Referencias a variables del lenguaje principal en aplicaciones de SQL



v “Declaración de variables del lenguaje principal de referencia de archivos en

aplicaciones de SQL incorporado REXX” en la página 148



Variables del lenguaje principal en aplicaciones de SQL incorporado

Variables del lenguaje principal en aplicaciones de SQL

incorporado

Las variables del lenguaje principal son variables a las que hacen referencia las

sentencias de SQL incorporado. Se utilizan para intercambiar valores de datos entre

el servidor de bases de datos y la aplicación de SQL incorporado. Las aplicaciones

de SQL incorporado también pueden incluir declaraciones de variables del

lenguaje principal para consultas de SQL relacional. Además, se puede utilizar una

variable del lenguaje principal para que contenga una expresión XQuery que se va

a ejecutar. Sin embargo, no hay ningún mecanismo para pasar valores a parámetros

en expresiones XQuery.

Las variables del lenguaje principal se declaran utilizando la sintaxis de

declaración de variables específica del lenguaje principal en una sección de

declaración.

Una sección de declaración es la parte de una aplicación de SQL incorporado que

se encuentra junto a la parte superior de un archivo de código fuente de SQL

incorporado y que se vincula mediante dos sentencias de SQL no ejecutables:

v BEGIN DECLARE SECTION

v END DECLARE SECTION

Estas sentencias permiten al precompilador encontrar las declaraciones de las

variables. Cada declaración de variable del lenguaje principal debe aparecer entre

estas dos sentencias; de lo contrario, las variables se consideran variables normales.

Las siguientes normas se aplican a secciones de declaración de variables del

lenguaje principal:

v Todas las variables del lenguaje principal se deben declarar en el archivo fuente,

dentro de una sección de declaración bien formada, antes de que se haga

referencia a las mismas, excepto para las variables del lenguaje principal que

hacen referencia a estructuras SQLDA.

v Se pueden utilizar varias secciones declare en un archivo fuente.

v Los nombres de variables del lenguaje principal deben ser exclusivos dentro de

un archivo fuente. Esto se debe a que el precompilador de DB2 no es

responsable de las normas de ámbito de variables específicas del lenguaje

principal. Como tal, sólo hay un ámbito para las variables del lenguaje principal.

Nota: Esto no significa que el precompilador de DB2 cambie el ámbito de

variables del lenguaje principal por global para que se pueda acceder a

las mismas fuera del ámbito en el que se han definido.

Supongamos que tenemos el siguiente ejemplo:

foo1(){

.

.

.

BEGIN SQL DECLARE SECTION;

int x;

END SQL DECLARE SECTION;


x=10;

.

.

.

}

foo2(){

.

.

.

y=x;

.

.

.

}

En función del lenguaje, el ejemplo anterior no se podrá compilar porque la

variable x no está declarada en la función foo2() o el valor de x no se establecerá

en 10 en foo2(). Para evitar este problema, debe declarar x como una variable

global o pasar x como parámetro a la función foo2() del siguiente modo:

foo1(){

.

.

.

BEGIN SQL DECLARE SECTION;

int x;

END SQL DECLARE SECTION;

x=10;

foo2(x);

.

.

.

}

foo2(int x){

.

.

.

y=x;

.

.

.

}



en la página 86






v “Declaración de variables del lenguaje principal con el Generador de

declaraciones db2dclgn” en la página 77





v “Sentencia END DECLARE SECTION” en Consulta de SQL, Volumen 2

v “Sentencia BEGIN DECLARE SECTION” en Consulta de SQL, Volumen 2



Para transmitir datos entre el servidor de bases de datos y la aplicación, tiene que

declarar variables del lenguaje principal en el código fuente de la aplicación para

cosas como consultas de SQL relacional y declaraciones de variables del lenguaje

principal para expresiones de XQuery.

Procedimiento:

La tabla siguiente contiene ejemplos de declaraciones de variables del lenguaje

principal para lenguajes principales de SQL incorporado.

Tabla 13. Declaraciones de variables del lenguaje principal por lenguaje principal

Lenguaje Código fuente de ejemplo

C y C++ EXEC SQL BEGIN DECLARE SECTION;

short dept=38, age=26;

double salary;

char CH;

char name1[9], NAME2[9];

short nul_ind;


COBOL EXEC SQL BEGIN DECLARE SECTION END-EXEC.

01 age PIC S9(4) COMP-5 VALUE 26.

01 DEPT PIC S9(9) COMP-5 VALUE 38.

01 salary PIC S9(6)V9(3) COMP-3.

01 CH PIC X(1).

01 name1 PIC X(8).

01 NAME2 PIC X(8).

01 nul-ind PIC S9(4) COMP-5.

EXEC SQL END DECLARE SECTION END-EXEC.

FORTRAN EXEC SQL BEGIN DECLARE SECTION

integer*2 age /26/

integer*4 dept /38/

real*8 salary

character ch

character*8 name1,NAME2

integer*2 nul_ind

EXEC SQL END DECLARE SECTION









Declaración de variables del lenguaje principal con el

Generador de declaraciones db2dclgn

Puede utilizar el Generador de declaraciones para generar declaraciones

correspondientes a una determinada tabla de una base de datos. Éste crea archivos

fuente de declaración en SQL incorporado que puede insertar fácilmente en las

aplicaciones. db2dclgn da soporte a los lenguajes C/C++, Java, COBOL y

FORTRAN.

Procedimiento:

Para generar archivos de declaración, entre el mandato db2dclgn en el siguiente

formato:

db2dclgn -d database-name -t table-name [options]

Por ejemplo, para generar las declaraciones para la tabla STAFF en la base de datos

SAMPLE en C en el archivo de salida staff.h, emita el siguiente mandato:

db2dclgn -d sample -t staff -l C

El archivo staff.h resultante contiene:

struct

{

short id;

struct

{

short length;

char data[9];

} name;

short dept;

char job[6];

short years;

double salary;

double comm;

} staff;


v “db2dclgn - Mandato Generador de declaraciones” en Consulta de mandatos

Tipos de datos de columna y variables del lenguaje principal


A cada columna de cada tabla de DB2 se asigna un tipo de datos de SQL cuando se

crea la columna. Para obtener información sobre cómo se asignan estos tipos a

columnas, consulte la sentencia CREATE TABLE.

Notas:

1. Cada tipo de datos soportado puede tener el atributo NOT NULL. Esto se trata

como otro tipo.

2. Los de tipos de datos se puede ampliar definiendo tipos diferenciados

definidos por el usuario (UDT). Los UDT son tipos de datos separados que

utilizan la representación de uno de los tipos de SQL integrados.

Los lenguajes principales de SQL incorporado soportados tienen tipos de datos que

corresponden con la mayoría de los tipos de datos del gestor de bases de datos.

Sólo estos tipos de datos de lenguajes principales se pueden utilizar en

declaraciones de variables del lenguaje principal. Cuando el precompilador


encuentra una declaración de variable del lenguaje principal, determina el valor de

tipo de datos de SQL adecuado. El gestor de bases de datos utiliza este valor para

convertir los datos intercambiados entre él mismo y la aplicación.

Como programador de aplicaciones, es importante que comprenda el modo en que

el gestor de bases de datos maneja comparaciones y asignaciones entre distintos

tipos de datos. Explicado de forma sencilla, los tipos de datos deben ser

compatibles entre sí durante las operaciones de asignación y comparación, tanto si

el gestor de bases de datos trabaja con dos tipos de datos de columnas de SQL

como si lo hace con dos tipos de datos de lenguaje principal o con uno de cada.

La norma general de la compatibilidad de tipos de datos establece que todos los

tipos de datos numéricos soportados del lenguaje de sistema principal se pueden

comparar y asignar con todos los tipos de datos numéricos del gestor de bases de

datos y que todos los tipos de caracteres del lenguaje de sistema principal son

compatibles con todos los tipos de caracteres del gestor de bases de datos; los tipos

numéricos son incompatibles con los tipos de caracteres. Sin embargo, también hay

algunas excepciones a esta normal general, en función de la idiosincrasia del

lenguaje de sistema principal y de las limitaciones impuestas cuando se trabaja con

objetos grandes.

Dentro de sentencias de SQL, DB2 proporciona conversiones entre tipos de datos

compatibles. Por ejemplo, en la siguiente sentencia SELECT, SALARY y BONUS

son columnas de tipo DECIMAL; sin embargo, la compensación total de cada

empleado se devuelve como datos de tipo DOUBLE:

SELECT EMPNO, DOUBLE(SALARY+BONUS) FROM EMPLOYEE

Observe que la ejecución de la sentencia anterior incluye la conversión entre los

tipos de datos DECIMAL y DOUBLE.

Para que los resultados de la consulta resulten más fáciles de leer en pantalla,

puede utilizar la siguiente sentencia SELECT:

SELECT EMPNO, DIGIT(SALARY+BONUS) FROM EMPLOYEE

La función DIGITS utilizada en el ejemplo anterior devuelve una representación de

un número como una serie de caracteres.

Para convertir datos dentro de la aplicación, póngase en contacto con el proveedor

del compilador para obtener rutinas, clases, tipos integrados o API adicionales que

den soporte a esta conversión.

Si la página de códigos de la aplicación no coincide con la página de códigos de la

base de datos, es posible que los tipos de datos de caracteres también estén sujetos

a la conversión de caracteres.


v “Consideraciones sobre la conversión de datos” en Desarrollo de SQL y rutinas

externas

v “Conversión de caracteres entre distintas páginas de códigos” en Desarrollo de

SQL y rutinas externas






v “Sentencia CREATE TABLE” en Consulta de SQL, Volumen 2








en la página 72

Declaración de variables del lenguaje principal XML en


Para intercambiar datos XML entre el servidor de bases de datos y una aplicación

de SQL incorporado, tiene que declarar las variables del lenguaje principal en el

código fuente de la aplicación.

DB2 V9.1 incorpora un tipo de datos XML que almacena los datos XML en un

conjunto estructurado de nodos en un formato de árbol. Las columnas con este

tipo de datos XML se describen como un SQLTYPE de columna SQL_TYP_XML y

las aplicaciones pueden vincular varios tipos de datos específicos del lenguaje

como entradas o salidas en estas columnas o parámetros. Se puede acceder

directamente a las columnas XML mediante SQL, las extensiones de SQL/XML o

XQuery. El tipo de datos XML se aplica a más elementos que columnas. Las

funciones pueden tener argumentos de valores XML o generar valores XML. De

forma similar, los procedimientos almacenados pueden tomar valores XML como

parámetros de entrada y de salida. Finalmente, las expresiones de XQuery generan

valores XML independientemente de si acceden a columnas XML o no.

Los datos XML son de tipo carácter por naturaleza y tienen una codificación que

especifica el juego de caracteres utilizado. La codificación de los datos XML puede

determinarse externamente, que se deriva del tipo de aplicación base que contiene

la representación de serie serializada del documento XML. También puede

determinarse internamente, que requiere la interpretación de los datos. Para los

documentos codificados en Unicode, se recomienda utilizar un marcador de orden

de bytes (BOM), consistente en un código de carácter Unicode al principio de una

corriente de datos. El BOM se utiliza como una signatura que define el orden de

los bytes y el formato de codificación Unicode.

Los tipos existentes de carácter y binarios, que incluyen CHAR, VARCHAR, CLOB

y BLOB, se pueden utilizar además de las variables del lenguaje principal para

captar e insertar datos. Sin embargo, no estarán sujetos al análisis de XML

implícito, como lo estarían las variables del lenguaje principal XML. En su lugar, se

inserta y se aplica una función XMLPARSE explícita con eliminación de espacios

en blanco por omisión.

Restricciones:

Restricciones de XML y XQuery al desarrollar aplicaciones de SQL incorporado

Procedimiento:

Para declarar variables del lenguaje principal XML en aplicaciones de SQL

incorporado:


En la sección de declaración de la aplicación, declare las variables del lenguaje

principal XML como tipos de datos LOB:

v SQL TYPE IS XML AS CLOB(n) <nombre_varpral>

donde <nombre_varpral> es una variable del lenguaje principal CLOB que

contiene datos XML codificados en la página de códigos mixta de la aplicación.

v SQL TYPE IS XML AS DBCLOB(n) <nombre_varpral>

donde <nombre_varpral> es una variable del lenguaje principal DBCLOB que

contiene datos XML codificados en la página de códigos gráfica de la aplicación.

v SQL TYPE IS XML AS BLOB(n) <nombre_varpral>

donde <nombre_varpral> es una variable del lenguaje principal BLOB que

contiene datos XML codificados internamente1.

v SQL TYPE IS XML AS CLOB_FILE <nombre_varpral>

donde <nombre_varpral> es un archivo CLOB que contiene datos XML

codificados en la página de códigos mixta de la aplicación.

v SQL TYPE IS XML AS DBCLOB_FILE <nombre_varpral>

donde <nombre_varpral> es un archivo DBCLOB que contiene datos XML

codificados en la página de códigos gráfica de la aplicación.

v SQL TYPE IS XML AS BLOB_FILE <nombre_varpral>

donde <nombre_varpral> es un archivo BLOB que contiene datos XML

codificados internamente1.

Notas:

1. Consulte el algoritmo para determinar la codificación con especificaciones XML

1.0 (http://www.w3.org/TR/REC-xml/#sec-guessing-no-ext-info).






v “Background information on XML internal encoding” en XML Guide

v “XML data encoding” en XML Guide



página 166


v “Recomendaciones para desarrollar aplicaciones de SQL incorporado con XML y

XQuery” en la página 30

Identificar valores XML en una SQLDA

Para indicar que un tipo base alberga datos XML, el campo sqlname de SQLVAR se

debe actualizar del siguiente modo:

v sqlname.length debe ser 8

v Los dos primeros bytes de sqlname.data deben ser X’0000’

v El tercer y cuarto bytes de sqlname.data deben ser X’0000’


v El quinto byte de sqlname.data debe ser X’01’ (que recibe el nombre del

indicador de subtipo de XML sólo cuando se cumplen las dos primeras

condiciones)

v Los restantes bytes deben ser X’000000’

Si el indicador de subtipo de XML está establecido en una SQLVAR cuyo SQLTYPE

es no LOB, se devolverá un error SQL0804 (rc=115) en el momento de la ejecución.

Nota: SQL_TYP_XML sólo se puede devolver desde la sentencia DESCRIBE. Este

tipo no se puede utilizar para ninguna otra petición. La aplicación debe

modificar la SQLDA para que contenga un tipo binario o de carácter válido

y debe establecer el campo sqlname de forma adecuada para que indique los

los datos son XML.



página 74






v “Declaración de la estructura SQLDA en un programa de SQL ejecutado


Identificación de valores de SQL nulos con variables de

indicador de nulo

Las aplicaciones de SQL incorporado deben prepararse para recibir valores nulos

asociando una variable de indicador de nulo con cualquier variable del lenguaje

principal que pueda recibir un nulo. El gestor de bases de datos y la aplicación del

sistema principal comparten una variable de indicador. Por lo tanto, esta variable

se tiene que declarar en la aplicación como una variable del lenguaje principal, que

corresponde al tipo de datos de SQL SMALLINT.

Una variable de indicador de nulo se coloca en una sentencia de SQL

inmediatamente después de la variable del lenguaje principal y va precedida por

un signo de dos puntos. Un espacio puede separar la variable de indicador de nulo

de la variable del lenguaje principal, aunque no es necesario. Sin embargo, no

coloque una coma entre la variable del lenguaje principal y la variable de

indicador de nulo. También puede especificar una variable de indicador de nulo

utilizando la palabra clave INDICATOR opcional, que debe colocar entre la

variable del lenguaje principal y su indicador de nulo.

Se examina la variable de indicador de nulo para ver si contiene un valor negativo.

Si el valor no es negativo, la aplicación puede utilizar el valor devuelto de la

variable del lenguaje principal. Si el valor es negativo, el valor captado es nulo y la

variable del lenguaje principal no se debe utilizar. En este caso, el gestor de bases

de datos no cambia el valor de la variable del lenguaje principal.

Nota: Si el parámetro de configuración de base de datos dft_sqlmathwarn tiene el

valor ’YES’, el valor de la variable de indicador de nulo puede ser -2. Este

valor indica un nulo causado por la evaluación de una expresión con un


error aritmético o por un desbordamiento al intentar convertir el valor de

resultado numérico en la variable del lenguaje principal.

Si el tipo de datos puede manejar valores nulos, la aplicación debe proporcionar un

indicador de nulo. De lo contrario, puede producirse un error. Si no se utiliza un

indicador de valor nulo, se devuelve un SQLCODE -305 (SQLSTATE 22002).

Si la estructura SQLCA indica un aviso de truncamiento, se pueden examinar las

variables de indicador de nulo para ver si hay algún truncamiento. Si una variable

de indicador de nulo tiene un valor positivo, significa que se ha producido un

truncamiento.

v Si la parte de segundos de un tipo de datos TIME está truncada, el valor del

indicador de nulo contiene la parte en segundos de los datos truncados.

v Para todos los demás tipos de datos de serie, excepto para objetos grandes

(LOB), el valor del indicador de nulo representa la longitud real de los datos

devueltos. Los tipos diferenciados definidos por el usuario (UDT) se manejan del

mismo modo que su tipo base.

Cuando se procesan sentencias INSERT o UPDATE, el gestor de bases de datos

comprueba la variable de indicador de nulo, si la hay. Si la variable de indicador

es negativa, el gestor de bases de datos establece el valor de la columna de destino

en nulo, si se permiten valores nulos.

Si la variable de indicador de nulo es cero o positiva, el gestor de bases de datos

utiliza el valor de la variable del lenguaje principal asociada.

El campo SQLWARN1 de la estructura SQLCA puede contener un valor X o W si el

valor de una columna de serie está truncado cuando se asigna a una variable del

lenguaje principal. El campo contiene un valor N si un terminador de valores nulos

está truncado.

El gestor de bases de datos devuelve un valor X sólo si se cumplen todas las

condiciones siguientes:

v Existe una conexión de página de códigos combinada en la que la conversión de

datos de serie de caracteres de la página de códigos de la base de datos a la

página de códigos de la aplicación implica un cambio en la longitud de los

datos.

v Un cursor está bloqueado.

v La aplicación proporciona una variable de indicador de nulo.

El valor devuelto en la variable de indicador de nulo tendrá la longitud de la serie

de caracteres resultante en la página de códigos de la aplicación.

En los demás casos en los que interviene un truncamiento de datos (en contraste

con el truncamiento del terminador de nulo), el gestor de bases de datos devuelve

un valor W. En este caso, el gestor de bases de datos devuelve un valor en la

variable de indicador de nulo a la aplicación que tiene la longitud de la serie de

caracteres resultante en la página de códigos del elemento de lista select (la página

de códigos de la aplicación, la página de códigos de la base de datos o ninguna).

Para poder utilizar variables de indicador de nulo en el lenguaje principal, tiene

que declarar las variables de indicador de nulo. En el siguiente ejemplo, programas

C y C++ adecuados, la variable de indicador de nulo cmind se puede declarar del

siguiente modo:


EXEC SQL BEGIN DECLARE SECTION;

char cm[3];

short cmind;


La tabla siguiente contiene ejemplos correspondientes a los lenguajes principales

soportados:

Tabla 14. Variables de indicador de nulo por lenguaje principal


C y C++ EXEC SQL FETCH C1 INTO :cm INDICATOR :cmind;

if ( cmind < 0 )

printf( "Commission is NULL\n" );

COBOL EXEC SQL FETCH C1 INTO :cm INDICATOR :cmind END-EXEC

IF cmind LESS THAN 0

DISPLAY ’Commission is NULL’

FORTRAN EXEC SQL FETCH C1 INTO :cm INDICATOR :cmind

IF ( cmind .LT. 0 ) THEN

WRITE(*,*) ’Commission is NULL’

ENDIF

REXX CALL SQLEXEC ’FETCH C1 INTO :cm INDICATOR :cmind’

IF ( cmind < 0 )

SAY ’Commission is NULL’





página 190


página 191









v “Tipos de datos de columna y variables del lenguaje principal en aplicaciones de


Inclusión de las variables del lenguaje principal SQLSTATE y

SQLCODE en aplicaciones de SQL incorporado

La información de error se devuelve en los campos SQLCODE y SQLSTATE de la

estructura SQLCA, que se actualiza tras cada sentencia de SQL ejecutable y tras la

mayoría de las llamadas a API del gestor de bases de datos. Si la aplicación

cumple con el estándar FIPS 127-2, puede declarar las variables del lenguaje

principal llamadas SQLSTATE y SQLCODE en lugar de declarar de forma explícita

la estructura SQLCA en aplicaciones de SQL incorporado.


Requisitos previos:

v Se tiene que especificar la opción de PREP LANGLEVEL SQL92E

Procedimiento:

En el siguiente ejemplo, la aplicación comprueba el campo SQLCODE de la estructura

SQLCA para determinar si la actualización se ha realizado satisfactoriamente.

Tabla 15. Incorporación de sentencias de SQL en un lenguaje principal


C y C++ EXEC SQL UPDATE staff SET job = ’Clerk’ WHERE job = ’Mgr’;

if ( SQLCODE < 0 )

printf( "Update Error: SQLCODE = %ld \n", SQLCODE );

COBOL EXEC SQL UPDATE staff SET job = ’Clerk’ WHERE job = ’Mgr’ END_EXEC.

IF SQLCODE LESS THAN 0

DISPLAY ’UPDATE ERROR: SQLCODE = ’, SQLCODE.

FORTRAN EXEC SQL UPDATE staff SET job = ’Clerk’ WHERE job = ’Mgr’

if ( sqlcode .lt. 0 ) THEN

write(*,*) ’Update error: sqlcode = ’, sqlcode




página 150


página 74


v “Declaración de la SQLCA para el manejo de errores” en la página 56


v “Sentencia PREPARE” en Consulta de SQL, Volumen 2

Cómo hacer referencia a variables del lenguaje principal en


Cuando haya declarado una variable del lenguaje principal en el código de la

aplicación de SQL incorporado, puede hacer referencia a la misma posteriormente

en la aplicación. Cuando utilice una variable del lenguaje principal en una

sentencia de SQL, preceda su nombre con un signo de dos puntos (:). Si utiliza una

variable del lenguaje principal en sintaxis de programación del lenguaje principal,

omita el signo de dos puntos.

Procedimiento:

Haga referencia a las variables del lenguaje principal utilizando la sintaxis

correspondiente al lenguaje principal que esté utilizando. La tabla siguiente

contiene ejemplos.

Tabla 16. Referencias a variables del lenguaje principal por lenguaje principal


C o C++ EXEC SQL FETCH C1 INTO :cm;

printf( "Commission = %f\n", cm );


Tabla 16. Referencias a variables del lenguaje principal por lenguaje principal (continuación)


COBOL EXEC SQL FETCH C1 INTO :cm END-EXEC

DISPLAY ’Commission = ’ cm

FORTRAN EXEC SQL FETCH C1 INTO :cm

WRITE(*,*) ’Commission = ’, cm

REXX CALL SQLEXEC ’FETCH C1 INTO :cm’

SAY ’Commission = ’ cm



página 74








Ejemplo: cómo hacer referencia a variables del lenguaje

principal XML en aplicaciones de SQL incorporado

Las siguientes aplicaciones de ejemplo hacen una demostración de cómo hacer

referencia a las variable del lenguaje principal XML en C y en COBOL.

Ejemplo: aplicación C de SQL incorporado:

El siguiente ejemplo de código se ha formateado para clarificarlo:

EXEC SQL BEGIN DECLARE;

SQL TYPE IS XML AS CLOB( 10K ) xmlBuf;

SQL TYPE IS XML AS BLOB( 10K ) xmlblob;

SQL TYPE IS CLOB( 10K ) clobBuf;


// como XML AS CLOB

// Al valor de XML escrito en xmlBuf se añadirá como prefijo una declaración

// de XML parecida a: <?xml version = "1.0" encoding = "ISO-8859-1" ?>

// Nota: el nombre de codificación dependerá de la página de códigos de la

// aplicación

EXEC SQL SELECT xmlCol INTO :xmlBuf

FROM myTable

WHERE id = ’001’;

EXEC SQL UPDATE myTable

SET xmlCol = :xmlBuf


// como XML AS BLOB

// Al valor de XML escrito en xmlblob se añadirá como prefijo una declaración

// de XML parecida a: <?xml version = "1.0" encoding = "UTF-8"?>

EXEC SQL SELECT xmlCol INTO :xmlblob

FROM myTable



SET xmlCol = :xmlblob


// como CLOB


// La salida estará codificada en la página de códigos de caracteres de la

// aplicación, pero nt contendrá una declaración XML

EXEC SQL SELECT XMLSERIALIZE (xmlCol AS CLOB(10K)) INTO :clobBuf

FROM myTable



SET xmlCol = XMLPARSE (:clobBuf PRESERVE WHITESPACE)


Ejemplo: aplicación COBOL de SQL incorporado:

El siguiente ejemplo de código se ha formateado para clarificarlo:

EXEC SQL BEGIN DECLARE SECTION END-EXEC.

01 xmlBuf USAGE IS SQL TYPE IS XML as CLOB(5K).

01 clobBuf USAGE IS SQL TYPE IS CLOB(5K).

01 xmlblob USAGE IS SQL TYPE IS BLOB(5K).


* como XML

EXEC SQL SELECT xmlCol INTO :xmlBuf

FROM myTable

WHERE id = ’001’.


SET xmlCol = :xmlBuf


* como BLOB

EXEC SQL SELECT xmlCol INTO :xmlblob

FROM myTable



SET xmlCol = :xmlblob


* como CLOB

EXEC SQL SELECT XMLSERIALIZE(xmlCol AS CLOB(10K)) INTO :clobBuf

FROM myTable

WHERE id= ’001’.


SET xmlCol = XMLPARSE(:clobBuf) PRESERVE WHITESPACE






página 166





incorporado C y C++


incorporado C y C++

Las variables del lenguaje principal son variables de los lenguajes C o C++ a las

que se hace referencia en las sentencias de SQL. Permiten a una aplicación

intercambiar datos con el gestor de bases de datos. Una vez que se ha

precompilado la aplicación, el compilador utiliza las variables del lenguaje


principal como cualquier otra variable de C o C++. Cuando denomine, declare y

utilice variables del lenguaje principal, siga las normas descritas en los apartados

siguientes.

Consideraciones sobre variables de tipo long:

En aplicaciones que construyen la SQLDA de forma manual, no se pueden utilizar

variables tipo long cuando sqlvar::sqltype==SQL_TYP_INTEGER. En su lugar se

deben utilizar los tipos sqlint32. Este problema es idéntico a utilizar variables

long en declaraciones de variables del lenguaje principal, excepto en que con una

SQLDA construida de forma manual el precompilador no revelará este error y se

producirán errores en el tiempo de ejecución.

Las conversiones de long y unsigned long que se utilizan para acceder a

información sqlvar::sqldata se deben cambiar por sqlint32 y sqluint32

respectivamente.Los miembros Val correspondientes a las estructuras sqloptions y

sqla_option se declaran como sqluintptr. Por lo tanto, la asignación de miembros

de puntero en miembros sqla_option::val o sqloptions::val deben utilizar

conversiones sqluintptr en lugar de conversiones unsigned long. Este cambio no

ocasionará problemas en el tiempo de ejecución en los sistemas operativos UNIX y

Linux, pero se debe realizar como preparación para aplicaciones Windows de 64

bits, en las que el tipo long sólo es de 32 bits.

Consideraciones sobre la codificación de varios bytes:

Algunos esquemas de codificación de caracteres, especialmente aquéllos que

proceden de los países del este asiático, necesitan varios bytes para representar un

carácter. Esta representación externa de los datos se denomina representación de

un carácter por medio de código de caracteres de varios bytes e incluye los caracteres

de doble byte (caracteres representados por dos bytes). Las variables del lenguaje

principal se elegirán consecuentemente, puesto que los datos gráficos de DB2

constan de caracteres de doble byte.

Para manipular series de caracteres que contienen caracteres de doble byte puede

resultar conveniente que una aplicación utilice una representación interna de los

datos. Esta representación interna se denomina representación de caracteres de

doble byte por medio de código de caracteres amplios y es el formato utilizado

habitualmente en el tipo de datos wchar_t de C o C++. Se dispone de subrutinas

que se ajustan a C de ANSI y a X/OPEN Portability Guide 4 (XPG4) para procesar

los datos de caracteres amplios y para convertir los datos que se encuentran en

este formato al formato de varios bytes, y viceversa.

Observe que, aunque una aplicación puede procesar datos de tipo carácter en

formato de varios bytes o en formato de caracteres amplios, la interacción con el

gestor de bases de datos sólo se realiza con códigos de caracteres DBCS (de varios

bytes). Es decir, los datos se almacenan y se recuperan de las columnas GRAPHIC

en formato DBCS. Se proporciona la opción WCHARTYPE del precompilador para

permitir que los datos de una aplicación que están en formato de caracteres

amplios se conviertan al formato de varios bytes, y viceversa, cuando se produce el

intercambio de datos con el motor de la base de datos.


v “Declaración de variables de tipo graphic del lenguaje principal en aplicaciones

de SQL incorporado C y C++” en la página 96


v “Soporte de estructuras del lenguaje principal en la sección de declaración de










v “Declaración de variables del lenguaje principal de tipo carácter de longitud fija,

terminadas en nulo y de longitud variable en aplicaciones de SQL incorporado C





v “Declaración de variables del lenguaje principal de tipo objeto grande (large

object) en aplicaciones de SQL incorporado C y C++” en la página 103

v “Declaración de variables del lenguaje principal de tipo localizador de objeto

grande (large object locator) en aplicaciones de SQL incorporado C y C++” en la

página 105

v “Declaración de variables numéricas del lenguaje principal en aplicaciones de


Nombres de variables del lenguaje principal en aplicaciones de

SQL incorporado C y C++

El precompilador SQL identifica las variables del lenguaje principal por el nombre

declarado para éstas. Se aplican las normas siguientes:

v Los nombres de las variables del lenguaje principal no deben superar los 255

caracteres de longitud.

v Los nombres de las variables del lenguaje principal no deben utilizar el prefijo

SQL, sql, DB2 ni db2, que están reservados para uso del sistema. Por ejemplo:


char varsql; /* permitido */

char sqlvar; /* no permitido */

char SQL_VAR; /* no permitido */


v El precompilador considera los nombres de variables del lenguaje principal

como globales respecto a un módulo. Sin embargo, esto no significa que las

variables del lenguaje principal se tengan que definir como variables globales; es

perfectamente aceptable que se declaren variables del lenguaje principal como

variables locales dentro de funciones. Por ejemplo, el código siguiente

funcionará correctamente:

void f1(int i)

{


short host_var_1;


EXEC SQL SELECT COL1 INTO :host_var_1 from TBL1;

}

void f2(int i)

{



short host_var_2;


EXEC SQL INSERT INTO TBL1 VALUES (:host_var_2);

}

También es posible tener varias variables del lenguaje principal locales con el

mismo nombre, siempre que sean del mismo tipo y tamaño. Para ello, declare la

primera aparición de la variable del lenguaje principal, ante el precompilador,

entre sentencias BEGIN DECLARE SECTION y END DECLARE SECTION, y

deje las declaraciones posteriores de la variable fuente de las secciones de

declaración. El código siguiente muestra un ejemplo de este caso:

void f3(int i)

{


char host_var_3[25];


EXEC SQL SELECT COL2 INTO :host_var_3 FROM TBL2;

}

void f4(int i)

{

char host_var_3[25];

EXEC SQL INSERT INTO TBL2 VALUES (:host_var_3);

}

Puesto que f3 y f4 están en el mismo módulo y host_var_3 tiene el mismo tipo

y longitud en ambas funciones, basta una sola declaración ante el precompilador

para utilizarla en ambos lugares.








v “Ejemplos de C++” en Temas de ejemplos



Sección declare para variables del lenguaje principal en


Se debe utilizar una sección de declaración de SQL para identificar las

declaraciones de variables del lenguaje principal. Esto alerta al precompilador

acerca de las variables del lenguaje principal a las que se puede hacer referencia en

sentencias de SQL posteriores. Por ejemplo:


char varsql; /* permitido */


El precompilador C o C++ sólo reconoce un subconjunto de declaraciones de C o

C++ válidas como declaraciones de variables del lenguaje principal válidas. Estas

declaraciones definen variables numéricas o de tipo carácter. No se admiten las

definiciones de tipo para los tipos de variable del lenguaje principal. Las variables

del lenguaje principal se pueden agrupar en una sola estructura de lenguaje

principal. Puede declarar miembros de datos de clase C++ como variables del

lenguaje principal.


Una variable numérica del lenguaje principal se puede utilizar como variable de

entrada o de salida para cualquier valor numérico de entrada o salida de SQL. Una

variable del lenguaje principal de tipo carácter se puede utilizar como variable de

entrada o de salida para cualquier valor de tipo carácter, de fecha, de hora o de

indicación horaria, de entrada o salida de SQL. La aplicación se tiene que asegurar

de que las variables de salida sean lo suficientemente largas como para contener

los valores que reciben.


v “Declaración de miembros de datos de clase como variables del lenguaje

principal en aplicaciones de SQL incorporado C++” en la página 108











v “Declaración de variables del lenguaje principal de tipo estructurado” en

Desarrollo de SQL y rutinas externas




Ejemplo: Plantilla de sección declare de SQL para aplicaciones

de SQL incorporado C y C++

A continuación se muestra una sección de declaración de SQL de ejemplo con

variables del lenguaje principal declaradas para tipos de datos SQL soportados:


... short age = 26; /* tipo de SQL 500 */

short year; /* tipo de SQL 500 */

sqlint32 salary; /* tipo de SQL 496 */

sqlint32 deptno; /* tipo de SQL 496 */

float bonus; /* tipo de SQL 480 */

double wage; /* tipo de SQL 480 */

char mi; /* tipo de SQL 452 */

char name[6]; /* tipo de SQL 460 */

struct {

short len;

char data[24];

} address; /* tipo de SQL 448 */

struct {

short len;

char data[32695];

} voice; /* tipo de SQL 456 */

sql type is clob(1m)

chapter; /* tipo de SQL 408 */

sql type is clob_locator

chapter_locator; /* tipo de SQL 964 */


sql type is clob_file

chapter_file_ref; /* tipo de SQL 920 */

sql type is blob(1m)

video; /* tipo de SQL 404 */

sql type is blob_locator

video_locator; /* tipo de SQL 960 */

sql type is blob_file

video_file_ref; /* tipo de SQL 916 */

sql type is dbclob(1m)

tokyo_phone_dir; /* tipo de SQL 412 */

sql type is dbclob_locator

tokyo_phone_dir_lctr; /* tipo de SQL 968 */

sql type is dbclob_file

tokyo_phone_dir_flref; /* tipo de SQL 924 */

struct {

short len;

sqldbchar data[100];

} vargraphic1; /* tipo de SQL 464 */

/* Precompilado con la

opción WCHARTYPE NOCONVERT */

struct {

short len;

wchar_t data[100];

} vargraphic2; /* tipo de SQL 464 */


opción WCHARTYPE CONVERT */

struct {

short len;


} long_vargraphic1; /* tipo de SQL 472 */



struct {

short len;

wchar_t data[10000];

} long_vargraphic2; /* tipo de SQL 472 */



sqldbchar graphic1[100]; /* tipo de SQL 468 */



wchar_t graphic2[100]; /* tipo de SQL 468 */



char date[11]; /* tipo de SQL 384 */

char time[9]; /* tipo de SQL 388 */

char timestamp[27]; /* tipo de SQL 392 */

short wage_ind; /* Indicador de nulo */

... EXEC SQL END DECLARE SECTION;







en la página 86







Variables SQLSTATE y SQLCODE en una aplicación de SQL

incorporado C y C++

Cuando se utiliza la opción de precompilación LANGLEVEL con un valor de

SQL92E, se pueden incluir las dos declaraciones siguientes como variables del

lenguaje principal:


char SQLSTATE[6]

sqlint32 SQLCODE;


Se supone la declaración SQLCODE durante el paso de precompilación. Observe

que, si se utiliza esta opción, no se debe especificar la sentencia INCLUDE SQLCA.

En una aplicación formada por varios archivos fuente, las variables SQLCODE y

SQLSTATE se pueden definir en el primer archivo fuente, tal como en el ejemplo

anterior. Los archivos fuente posteriores deben modificar las definiciones del modo

siguiente:

extern sqlint32 SQLCODE;

extern char SQLSTATE[6];





página 190


en la página 86

Declaración de variables numéricas del lenguaje principal en


A continuación se muestra la sintaxis para declarar variables numéricas del

lenguaje principal en C o C++.

��

auto

extern

static

register

const

volatile

(1)

float

(2)

double

(3)

short

int

INTEGER (SQLTYPE 496)

BIGINT (SQLTYPE 492)

�


�

�

�

,

nombrevar

=

valor

*

&

const

volatile

;

��

INTEGER (SQLTYPE 496)

sqlint32

(4)

long

int

BIGINT (SQLTYPE 492)

sqlint64

__int64

long long

int

(5)

long

int

Notas:

1 REAL (SQLTYPE 480), longitud 4

2 DOUBLE (SQLTYPE 480), longitud 8

3 SMALLINT (SQLTYPE 500)

4 Para obtener una portabilidad máxima de las aplicaciones utilice,

respectivamente, sqlint32 y sqlint64 para las variables del lenguaje principal

INTEGER y BIGINT. Por omisión, el uso de variables del lenguaje principal

tipo long tiene como consecuencia el error del precompilador SQL0402 en las

plataformas en que la longitud es una cantidad de 64 bits, como por ejemplo

en UNIX de 64 BITS. Utilice la opción LONGERROR NO de PREP para

imponer que DB2 acepte variables long como tipos de variable del lenguaje

principal aceptables y las trate como variables BIGINT.

5 Para obtener una portabilidad máxima de las aplicaciones utilice,

respectivamente, sqlint32 y sqlint64 para las variables del lenguaje

principal INTEGER y BIGINT. Para utilizar el tipo de datos BIGINT, la

plataforma tiene que soportar valores enteros de 64 bits. Por omisión, el uso

de variables del lenguaje principal tipo long tiene como consecuencia el error

del precompilador SQL0402 en las plataformas en que la longitud es una

cantidad de 64 bits, como por ejemplo en UNIX de 64 BITS. Utilice la opción

LONGERROR NO de PREP para imponer que DB2 acepte variables long

como tipos de variable del lenguaje principal aceptables y las trate como

variables BIGINT.






en la página 86

Declaración de variables del lenguaje principal de tipo carácter

de longitud fija, terminadas en nulo y de longitud variable en


A continuación se muestra la sintaxis para declarar variables del lenguaje principal

de tipo carácter fijas, terminadas en nulo (formato 1) y de longitud variable en C o

C++.

Formato 1: Sintaxis correspondiente a variables del lenguaje principal de tipo

carácter fijas y terminadas en nulo en aplicaciones de SQL incorporado en C

o C++

��

auto

extern

static

register

const

volatile

char

unsigned �

�

�

,

CHAR

Serie C

=

valor

;

��

CHAR

�

(1)

nombrevar

*

&

const

volatile

Serie C

�

(2)

nombrevar

[longitud]

(

nombrevar

)

*

&

const

volatile

Notas:

1 CHAR (SQLTYPE 452), length 1

2 Serie C terminada en nulo (SQLTYPE 460); la longitud puede ser cualquier

expresión constante válida


Formato 2: Sintaxis correspondiente a variables del lenguaje principal de tipo

carácter de longitud variable en aplicaciones de SQL incorporado C y C++

��

auto

extern

static

register

const

volatile

struct

código �

� (1)

{

short

var1

;

char

var2

[longitud]

;

}

int

unsigned

�

�

�

�

,

nombrevar

Valores

*

&

const

volatile

;

��

Valores

= { valor-1 , valor-2 }

Notas:

1 En el formato 2, la longitud puede ser cualquier expresión constante válida.

Su valor después de una evaluación determina si la variable del lenguaje

principal es VARCHAR (SQLTYPE 448) o LONG VARCHAR (SQLTYPE 456).

Consideraciones sobre las variables del lenguaje principal de tipo carácter de

longitud variable:

1. Aunque el gestor de bases de datos convierte los datos de tipo carácter al

formato 1 o al formato 2 siempre que es posible, el formato 1 corresponde a los

tipos de columna CHAR o VARCHAR, mientras que el formato 2 corresponde

a los tipos de columna VARCHAR y LONG VARCHAR.

2. Si se utiliza el formato 1 con un especificador de longitud [n], el valor

correspondiente al especificador de longitud tras la evaluación no debe ser

mayor que 32672 y la serie contenida en la variable debe terminar en nulo.

3. Si se utiliza el formato 2, el valor correspondiente al especificador de longitud

tras la evaluación no debe ser mayor que 32700.

4. En el formato 2, var1 y var2 deben ser simples referencias a variables (y no

operadores) y no se pueden utilizar como variables del lenguaje principal

(nombrevar es la variable del lenguaje principal).

5. nombrevar puede ser un simple nombre de variable o puede incluir operadores,

como por ejemplo *nombrevar. Consulte la descripción de los tipos de datos de

puntero en C y C++ para obtener más información.

6. El precompilador determina el SQLTYPE y la SQLLEN de todas las variables

del lenguaje principal. Si una variable del lenguaje principal aparece en una

sentencia de SQL con una variable de indicador, mientras dure esa sentencia se

asigna como SQLTYPE el SQLTYPE base más uno.


7. El precompilador permite algunas declaraciones que no son válidas

sintácticamente en C ni en C++. Si tiene dudas acerca de la sintaxis de una

declaración determinada, consulte la documentación del compilador.


v “Series terminadas en nulo en aplicaciones de SQL incorporado C y C++” en la

página 117



Declaración de variables de tipo graphic del lenguaje principal

en aplicaciones de SQL incorporado C y C++

Para manejar datos gráficos en aplicaciones C o C++, utilice variables de lenguaje

principal basadas en el tipo de datos wchar_t de C o C++ o en el tipo de datos

sqldbchar proporcionado por DB2. Puede asignar estos tipos de variables del

lenguaje principal a las columnas de una tabla que sean GRAPHIC, VARGRAPHIC

o DBCLOB. Por ejemplo, puede actualizar o seleccionar datos DBCS de las

columnas GRAPHIC o VARGRAPHIC de una tabla.

Existen tres formatos válidos para una variable gráfica del lenguaje principal:

v Formato de gráfico simple

Las variables de gráfico simple del lenguaje principal tienen para SQLTYPE el

valor 468/469, lo que equivale al tipo de datos GRAPHIC(1) de SQL.

v Formato de gráfico terminado en nulo

Terminado en nulo hace referencia a una situación en que todos los bytes del

último carácter de la serie gráfica contienen ceros binarios ('\0's). Su tipo de

datos de SQL es 400/401.

v Formato estructurado VARGRAPHIC

Las variables de formato estructurado VARGRAPHIC del lenguaje principal

tienen para SQLTYPE el valor 464/465 si su longitud está comprendida entre 1 y

16.336 bytes. Tienen para SQLTYPE el valor 472/473 si su longitud está

comprendida entre 2.000 y 16.350 bytes.












v “Tipos de datos wchar_t y sqldbchar para datos gráficos en aplicaciones de SQL


v “Opción del precompilador WCHARTYPE para datos gráficos en aplicaciones de






v “Declaración de variables de tipo GRAPHIC del lenguaje principal en formatos

de un solo gráfico y de gráficos terminados en nulo en aplicaciones de SQL


v “Declaración de variables del lenguaje principal de tipo VARGRAPHIC en el

formato estructurado en aplicaciones de SQL incorporado C o C++” en la página

101




grande (large object locator) en aplicaciones de SQL incorporado C y C++” en la

página 105

Tipos de datos wchar_t y sqldbchar para datos gráficos en


Mientras que el tamaño y la codificación de datos gráficos de DB2 son constantes

en todas las plataformas para una página de códigos determinada, el tamaño y el

formato interno del tipo de datos wchar_t de C o de C++ de ANSI dependen del

compilador que se utilice y de la plataforma en que se encuentre. No obstante,

DB2 define el tipo de datos sqldbchar con un tamaño de dos bytes, y se pretende

que constituya una manera portátil de manipular los datos DBCS y UCS-2 en el

mismo formato en que están almacenados en la base de datos.

Puede definir todos los tipos de variables del lenguaje principal de gráficos C de

DB2 mediante wchar_t o sqldbchar. Debe utilizar wchar_t si crea la aplicación

mediante la opción de precompilación WCHARTYPE CONVERT.

Nota: Cuando especifique la opción WCHARTYPE CONVERT en un sistema

operativo Windows, tenga en cuenta que wchar_t en sistemas operativos

Windows es Unicode. Por lo tanto, si el wchar_t del compilador C o C++ no

es Unicode, es posible que la llamada a la función wcstombs() falle con

SQLCODE -1421 (SQLSTATE=22504). Si esto sucede, puede especificar la

opción WCHARTYPE NOCONVERT y llamar a las funciones wcstombs() y

mbstowcs() de forma explícita desde dentro del programa.

Si crea la aplicación con la opción de precompilación WCHARTYPE NOCONVERT,

debe utilizar sqldbchar para conseguir una portabilidad máxima entre distintas

plataformas de cliente y servidor DB2. Puede utilizar wchar_t con WCHARTYPE

NOCONVERT, pero sólo en aquellas plataformas en que wchar_t esté definido con

una longitud de dos bytes.

Si utiliza incorrectamente wchar_t o sqldbchar en declaraciones de variables del

lenguaje principal, durante la precompilación recibirá un SQLCODE 15 (sin

SQLSTATE).


v “Consideraciones sobre el juego de códigos EUC y UCS-2 japonés y chino

tradicional” en Desarrollo de SQL y rutinas externas




Opción del precompilador WCHARTYPE para datos gráficos en


Mediante la opción WCHARTYPE del precompilador, puede especificar el formato

de caracteres gráficos que desea utilizar en la aplicación C o C++. Esta opción

proporciona flexibilidad para elegir entre tener los datos gráficos en formato de

varios bytes o en formato de caracteres amplios. La opción WCHARTYPE tiene dos

valores posibles:

CONVERT

Si se selecciona la opción WCHARTYPE CONVERT, se convierten los

códigos de caracteres entre la variable de gráficos del lenguaje principal y

el gestor de bases de datos. Para las variables del lenguaje principal de

entrada de gráficos, la conversión de código de caracteres del formato de

caracteres amplios a formato de caracteres DBCS de varios bytes se realiza

antes de enviar los datos al gestor de bases de datos, mediante la función

wcstombs() de C de ANSI. Para las variables del lenguaje principal de

salida de gráficos, la conversión de código de caracteres del formato de

caracteres DBCS de varios bytes al formato de caracteres amplios se realiza

antes de que los datos recibidos del gestor de bases de datos se almacenen

en la variable del lenguaje principal, mediante la función mbstowcs() de C

de ANSI.

La ventaja de utilizar WCHARTYPE CONVERT es que permite que la

aplicación aproveche plenamente los mecanismos de C de ANSI para tratar

las series de caracteres amplios (literales L, funciones de serie ’wc’, etc.) sin

tener que convertir los datos de forma explícita al formato de varios bytes

antes de establecer comunicación con el gestor de bases de datos. El

inconveniente es que las conversiones implícitas puede tener un impacto

sobre el rendimiento de la aplicación durante la ejecución de ésta y pueden

incrementar los requisitos de memoria.

Si selecciona WCHARTYPE CONVERT, declare todas las variables del

lenguaje principal de gráficos mediante wchar_t en lugar de mediante

sqldbchar.

Si desea el comportamiento de WCHARTYPE CONVERT pero no es

necesario precompilar la aplicación (por ejemplo, una aplicación CLI),

defina la macro SQL_WCHART_CONVERT del preprocesador de C durante la

compilación. Así se asegurará de que determinadas definiciones de los

archivos de cabecera de DB2 utilicen el tipo de datos wchar_t en lugar de

sqldbchar.

Nota: La opción de precompilación WCHARTYPE CONVERT no recibe

soporte en programas que se ejecutan en el cliente DB2 Windows

3.1. Para estos programas, utilice el valor por omisión

(WCHARTYPE NOCONVERT).

NOCONVERT (valor por omisión)

Si se elige la opción WCHARTYPE NOCONVERT o no se especifica

ninguna opción WCHARTYPE, no se produce ninguna conversión

implícita del código de caracteres entre la aplicación y el gestor de bases

de datos. Los datos de una variable del lenguaje principal de gráficos se

envían al gestor de bases de datos y se reciben del mismo como caracteres

DBCS inalterados. Esto tiene la ventaja de que se mejora el rendimiento,

pero el inconveniente de que la aplicación debe abstenerse de utilizar datos

de caracteres amplios en las variables del lenguaje principal wchar_t, o

tiene que llamar explícitamente a las funciones wcstombs() y mbstowcs()


para convertir los datos al formato de varios bytes, o viceversa, cuando

interactúe con el gestor de bases de datos.

Si selecciona WCHARTYPE NOCONVERT, declare todas las variables del

lenguaje principal de gráficos utilizando el tipo sqldbchar, a fin de obtener

la máxima portabilidad a otras plataformas cliente/servidor de DB2.

Hay otras directrices que debe tener en cuenta, que son las siguientes:

v Puesto que se utiliza el soporte de wchar_t o sqldbchar para manejar datos

DBCS, su uso requiere que el hardware y el software tengan capacidad de DBCS

o EUC. Este soporte sólo está disponible en el entorno DBCS de DB2 Database

para Linux, UNIX y Windows, o para tratar datos GRAPHIC en cualquier

aplicación (incluidas las aplicaciones de un solo byte) conectada a una base de

datos UCS-2.

v Los caracteres que no sean DBCS, y los caracteres amplios que se pueden

convertir en caracteres no DBCS, no se deben utilizar en series gráficas.

Caracteres que no sean DBCS hace referencia a los caracteres de un solo byte y a

los caracteres que no son de doble byte. Las series gráficas no se validan para

asegurar que sus valores únicamente contienen puntos de código de caracteres

de doble byte. Las variables del lenguaje principal de gráficos sólo deben

contener datos DBCS o, si WCHARTYPE CONVERT está en vigor, datos de

caracteres amplios que se convierten en datos DBCS. Debe almacenar los datos

que contienen una mezcla de caracteres de doble byte y de un solo byte en

variables del lenguaje principal de tipo carácter. Observe que las variables del

lenguaje principal de datos mixtos no se ven afectadas por el establecimiento de

la opción WCHARTYPE.

v En las aplicaciones en que se utiliza la opción de precompilación WCHARTYPE

NOCONVERT, no se deben utilizar literales L junto con variables del lenguaje

principal de gráficos, puesto que los literales L están en formato de caracteres

amplios. Un literal L es una serie de caracteres amplios C que tiene como prefijo

la letra L y como tipo de datos "array of wchar_t". Por ejemplo,

L"dbcs-string" es un literal L.

v En las aplicaciones en que se utiliza la opción de precompilación WCHARTYPE

CONVERT, se pueden utilizar literales L para inicializar variables del lenguaje

principal wchar_t, pero no se pueden utilizar en sentencias de SQL. En lugar de

utilizar literales L, las sentencias de SQL deben usar constantes de serie de

gráficos, que son independientes del valor de WCHARTYPE.

v El valor de la opción WCHARTYPE afecta a los datos de gráficos que se pasan

al gestor de bases de datos y que se reciben de éste utilizando la estructura

SQLDA, así como a las variables del lenguaje principal. Si WCHARTYPE

CONVERT está en vigor, se supondrá que los datos gráficos recibidos de la

aplicación mediante una SQLDA están en formato de caracteres amplios, y se

convertirán al formato DBCS a través de una llamada implícita a wcstombs(). De

forma parecida, los datos de salida de gráficos recibidos por una aplicación se

habrán convertido al formato de caracteres amplios antes de colocarlos en el

almacenamiento de la aplicación.

v Los procedimientos almacenados sin barrera se deben precompilar con la opción

WCHARTYPE NOCONVERT. Los procedimientos almacenados normales con

barrera se pueden precompilar con las opciones CONVERT o NOCONVERT, lo

cual afectará al formato de los datos gráficos manipulados por las sentencias de

SQL contenidas en el procedimiento almacenado. No obstante, y en cualquier

caso, los datos gráficos que se pasen al procedimiento almacenado mediante la

SQLDA estarán en formato DBCS. De la misma forma, los datos que se pasen

desde el procedimiento almacenado mediante la SQLDA deben estar en formato

DBCS.


v Si una aplicación llama a un procedimiento almacenado a través de la interfaz

Database Application Remote Interface (DARI) (la API sqleproc()), los datos

gráficos de la SQLDA de entrada tienen que estar en formato DBCS, o en UCS-2

si está conectada a una base de datos UCS-2, independientemente del estado del

valor de WCHARTYPE de la aplicación que realiza la llamada. Asimismo, los

datos gráficos de la SQLDA de salida se devolverán en formato DBCS, o en

UCS-2 si está conectada a una base de datos UCS-2, independientemente del

valor de WCHARTYPE.

v Si una aplicación llama a un procedimiento almacenado mediante la sentencia

CALL de SQL, se producirá una conversión de los datos gráficos en la SQLDA,

según el valor de WCHARTYPE de la aplicación que realiza la llamada.

v Los datos gráficos que se pasen a funciones definidas por el usuario (UDF)

siempre estarán en formato DBCS. De la misma forma, se supondrá que los

datos gráficos devueltos desde una UDF están en formato DBCS para las bases

de datos DBCS, y en formato UCS-2 para las bases de datos EUC y UCS-2.

v Los datos almacenados en archivos DBCLOB mediante el uso de variables de

referencia a archivos DBCLOB se almacenan en formato DBCS o, en el caso de

bases de datos UCS-2, en formato UCS-2. Del mismo modo, los datos de entrada

procedentes de archivos DBCLOB se recuperan en formato DBCS o, en el caso

de bases de datos UCS-2, en formato UCS-2.

Notas:

1. En el caso de DB2 para sistemas operativos Windows, la opción WCHARTYPE

CONVERT está soportada para aplicaciones compiladas con el compilador

Microsoft Visual C++. Sin embargo, no utilice la opción CONVERT con este

compilador si la aplicación inserta datos en una base de datos DB2 en una

página de códigos que sea diferente a la de la base de datos. En esta situación,

el servidor DB2 suele efectuar una conversión de página de códigos; no

obstante, el entorno de tiempo de ejecución de Microsoft C no maneja

caracteres de sustitución para algunos caracteres de doble byte. Esto podría

producir errores de conversión en tiempo de ejecución.

2. Si se precompilan aplicaciones C utilizando la opción WCHARTYPE

CONVERT, DB2 valida los datos gráficos de la aplicación tanto de entrada

como de salida, puesto que los datos se pasan a través de las funciones de

conversión. Si no se utiliza la opción CONVERT, no se produce ninguna

conversión de los datos gráficos, por lo que tampoco se produce ninguna

validación. En un entorno mixto de CONVERT/NOCONVERT, se pueden

ocasionar problemas si una aplicación NOCONVERT inserta datos gráficos no

válidos que luego son captados por una aplicación CONVERT. Estos datos no

se pueden convertir con SQLCODE -1421 (SQLSTATE 22504) en una operación

FETCH de la aplicación CONVERT.







v “Declaración de variables de tipo GRAPHIC del lenguaje principal en formatos

de un solo gráfico y de gráficos terminados en nulo en aplicaciones de SQL






48

Declaración de variables del lenguaje principal de tipo

VARGRAPHIC en el formato estructurado en aplicaciones de

SQL incorporado C o C++

A continuación se muestra la sintaxis para declarar una variable del lenguaje

principal gráfica mediante el formato estructurado VARGRAPHIC.

��

auto

extern

static

register

const

volatile

struct

código �

� (1) (2)

{

short

var-1

;

sqldbchar

var-2

[longitud

]

;

}

int

wchar_t

�

�

�

�

,

Variable

;

*

&

const

volatile

��

Variable:

nombre-variable

=

{

valor-1

,

valor-2

}

Notas:

1 Para determinar cuál de los dos tipos gráficos debe utilizar, consulte la

descripción de los tipos de datos wchar_t y sqldbchar en C y C++.

2 longitud puede ser cualquier expresión de constante válida. Su valor después

de una evaluación determina si la variable del lenguaje principal es

VARGRAPHIC (SQLTYPE 464) o LONG VARGRAPHIC (SQLTYPE 472). El

valor de longitud debe ser mayor o igual que 1 y menor o igual que la

longitud máxima de LONG VARGRAPHIC, que es 16350.

Consideraciones sobre la declaración de gráfico (formato estructurado

VARGRAPHIC):

1. var-1 y var-2 deben ser simples referencias a variables (y no operadores) y no se

pueden utilizar como variables del lenguaje principal.

2. valor-1 y valor-2 son inicializadores de var-1 y var-2. valor-1 debe ser un entero y

valor-2 debe ser un literal de serie de caracteres amplios (literal L) si se utiliza

la opción WCHARTYPE CONVERT del precompilador.

3. Se puede utilizar el código struct para definir otras áreas de datos, pero no se

puede utilizar por sí mismo como variable del lenguaje principal.





Declaración de variables de tipo GRAPHIC del lenguaje principal

en formatos de un solo gráfico y de gráficos terminados en nulo


A continuación se muestra la sintaxis para declarar una variable del lenguaje

principal gráfica mediante el formato de un solo gráfico y el formato de gráfico

terminado en nulo.

��

auto

extern

static

register

const

volatile

(1)

sqldbchar

wchar_t

�

�

�

,

CHAR

Serie C

=

valor

;

��

CHAR

�

(2)

nombrevar

*

&

const

volatile

Serie C

�

(3)

nombrevar

[longitud]

(

nombrevar

)

*

&

const

volatile

Notas:

1 Para determinar cuál de los dos tipos gráficos debe utilizar, consulte la

descripción de los tipos de datos wchar_t y sqldbchar en C y C++.

2 GRAPHIC (SQLTYPE 468), longitud 1

3 Serie gráfica terminada en nulo (SQLTYPE 400)

Consideraciones sobre variables del lenguaje principal de tipo graphic:

1. El formato de un solo gráfico declara una variable del lenguaje principal de

serie gráfica y longitud fija de longitud 1 con un SQLTYPE de 468 ó 469.


2. valor es un inicializador. Se debe utilizar un literal de serie de caracteres

amplios (literal L) si se utiliza la opción WCHARTYPE CONVERT del

precompilador.

3. longitud puede ser cualquier expresión constante válida, y su valor después de

una evaluación tiene que ser mayor o igual a 1 y no mayor que la longitud

máxima de VARGRAPHIC, que es 16336.

4. Las series gráficas terminadas en nulo se manejan de forma distinta en función

del valor del establecimiento de opciones de precompilación de nivel estándar.



página 117



Declaración de variables del lenguaje principal de tipo objeto

grande (large object) en aplicaciones de SQL incorporado C y

C++


de objeto grande (LOB) en C o C++.

��

auto

extern

static

register

const

volatile

SQL TYPE IS

XML AS BLOB

CLOB

DBCLOB

�

� (1)

(longitud

)

�

�

�

�

,

nombre-variable

Datos LOB

*

&

const

volatile

;

��

Datos LOB

={long-inic,″datos-inic″}

=SQL_BLOB_INIT(″datos-inic″)

=SQL_CLOB_INIT(″datos-inic″)

=SQL_DBCLOB_INIT(″datos-inic″)

Notas:

1 longitud puede ser cualquier expresión de constante válida en la que se

pueden utilizar las constantes K, M o G. El valor de la longitud después de


una evaluación para BLOB y CLOB debe ser 1 <= longitud <= 2.147.483.647.

El valor de longitud tras la evaluación correspondiente a DBCLOB debe ser 1

<= longitud <= 1.073.741.823.

Consideraciones sobre variables del lenguaje principal de tipo LOB:

1. Es necesaria la cláusula TYPE IS de SQL para poder distinguir los tres tipos de

LOB entre sí, de forma que se puedan llevar a cabo una comprobación del tipo

y una resolución de la función para las variables de lenguaje principal de tipo

LOB que se pasan a las funciones.

2. SQL TYPE IS, BLOB, CLOB, DBCLOB, K, M, G se pueden especificar en una

mezcla de mayúsculas y minúsculas.

3. La longitud máxima permitida para la serie de inicialización ″datos-inic″ es

32702 bytes, incluidos los delimitadores de la serie (igual al límite existente en

series C y C++ dentro del precompilador).

4. La longitud de inicialización, long-inic, tiene que ser una constante numérica

(por ejemplo, no puede incluir K, M ni G).

5. Se debe especificar una longitud para el LOB; es decir, que la declaración

siguiente no está permitida:

SQL TYPE IS BLOB my_blob;

6. Si el LOB no se inicializa dentro de la declaración, no se realizará ninguna

inicialización en el código generado por el precompilador.

7. Si se inicializa un DBCLOB, es responsabilidad del usuario añadirle a la serie el

prefijo ’L’ (que indica una serie de caracteres amplios).

Nota: Los literales de caracteres amplios, por ejemplo L"Hello", sólo se deben

utilizar en un programa precompilado si se selecciona la opción

WCHARTYPE CONVERT de precompilación.

8. El precompilador genera un código de estructura que se puede utilizar para

pasarlo al tipo de la variable del lenguaje principal.

Ejemplo de BLOB:

La declaración:

static Sql Type is Blob(2M) my_blob=SQL_BLOB_INIT("mydata");

Tiene como resultado la generación de la estructura siguiente:

static struct my_blob_t {

sqluint32 length;

char data[2097152];

} my_blob=SQL_BLOB_INIT("mydata");

Ejemplo de CLOB:

La declaración:

volatile sql type is clob(125m) *var1, var2 = {10, "data5data5"};


volatile struct var1_t {

sqluint32 length;

char data[131072000];

} * var1, var2 = {10, "data5data5"};

Ejemplo de DBCLOB:

La declaración:


SQL TYPE IS DBCLOB(30000) my_dbclob1;

Si se precompila con la opción WCHARTYPE NOCONVERT, tiene como resultado

la generación de la estructura siguiente:

struct my_dbclob1_t {

sqluint32 length;


} my_dbclob1;

La declaración:

SQL TYPE IS DBCLOB(30000) my_dbclob2 = SQL_DBCLOB_INIT(L"mydbdata");

Si se precompila con la opción WCHARTYPE CONVERT, tiene como resultado la

generación de la estructura siguiente:

struct my_dbclob2_t {

sqluint32 length;

wchar_t data[30000];

} my_dbclob2 = SQL_DBCLOB_INIT(L"mydbdata");


v “Declaración de variables del lenguaje principal como punteros en aplicaciones






v “Indicaciones horarias generadas por el precompilador” en la página 208





localizador de objeto grande (large object locator) en



de localizador de objeto grande (LOB) en C o C++.

��

auto

extern

static

register

const

volatile

SQL TYPE IS BLOB_LOCATOR

CLOB_LOCATOR

DBCLOB_LOCATOR

�

�

�

,

Variable

;

��

Variable


�

*

nombre-variable

&

const

= valor-inic

volatile

Consideraciones sobre variables del lenguaje principal de tipo localizador de

LOB:

1. SQL TYPE IS, BLOB_LOCATOR, CLOB_LOCATOR, DBCLOB_LOCATOR se

pueden especificar en una mezcla de mayúsculas y minúsculas.

2. valor-inic permite la inicialización de variables de localizador de puntero y

referencia. Otros tipos de inicialización no tendrán ningún significado.

Ejemplo de localizador de CLOB (las declaraciones de otros tipos de localizadores

de LOB son similares):

La declaración:

SQL TYPE IS CLOB_LOCATOR my_locator;

Tiene como resultado la generación de la declaración siguiente:

sqluint32 my_locator;







Declaración de variables del lenguaje principal de tipo referencia

de archivos en aplicaciones de SQL incorporado C y C++


de referencia de archivos en C o C++.


Nota: SQL TYPE IS, BLOB_FILE, CLOB_FILE, DBCLOB_FILE se pueden

especificar en una mezcla de mayúsculas y minúsculas.

Ejemplo de referencia de archivos CLOB (las declaraciones de otros tipos de

referencias de archivos LOB son similares):

La declaración:

static volatile SQL TYPE IS BLOB_FILE my_file;


static volatile struct {

sqluint32 name_length;

sqluint32 data_length;

sqluint32 file_options;

char name[255];

} my_file;

Nota: La estructura anterior es equivalente a la estructura de sqlfile que se

encuentra en la cabecera sql.h. Consulte la Figura 2 para ver el diagrama de

sintaxis.




Declaración de variables del lenguaje principal como punteros


Las variables del lenguaje principal se pueden declarar como punteros a tipos de

datos específicos, con las restricciones siguientes:

v Si una variable del lenguaje principal se declara como puntero, no se puede

declarar ninguna otra variable del lenguaje principal con el mismo nombre

dentro del mismo archivo fuente. El ejemplo siguiente no está permitido:

char mystring[20];

char (*mystring)[20];

Sintaxis para variables del lenguaje principal de referencia de archivos en C o C++

��

auto

extern

static

register

const

volatile

SQL TYPE IS

XML AS

BLOB_FILE

CLOB_FILE

DBCLOB_FILE

�

,

Variable

;

��

Variable

�

*

nombre-variable

&

const

= valor-inic

volatile

Figura 2. Diagrama de sintaxis


v Cuando declare un puntero a una matriz de caracteres terminada en nulo, utilice

paréntesis. En todos los casos restantes, no se permiten paréntesis. Por ejemplo:


char (*arr)[10]; /* correcto */

char *(arr); /* incorrecto */

char *arr[10]; /* incorrecto */


La primera declaración es un puntero a una matriz de caracteres de 10 bytes.

Esta variable del lenguaje principal es válida. La segunda declaración no es

válida. Los paréntesis no están permitidos en un puntero a un carácter. La

tercera declaración es una matriz de punteros. Este tipo de datos no se soporta.

La declaración de variable del lenguaje principal:

char *ptr;

se acepta, pero no significa serie de caracteres terminada en nulo de longitud

indeterminada; significa puntero a una variable del lenguaje principal de un solo

carácter y de longitud fija. Es posible que esto no fuera lo que se pretendía. Para

definir una variable del lenguaje principal de puntero que pueda indicar

distintas series de caracteres, utilice el primero de los formatos de declaración

anteriores.

v Cuando se utilizan variables del lenguaje principal de puntero en sentencias de

SQL, deben tener como prefijo el mismo número de asteriscos con que se han

declarado, tal como en el ejemplo siguiente:


char (*mychar)[20]; /* Puntero a matriz de caracteres de 20 bytes */


EXEC SQL SELECT column INTO :*mychar FROM table; /* Correcta */

v Sólo se puede utilizar el asterisco como operador en un nombre de variable del

lenguaje principal.

v La longitud máxima de un nombre de variable del lenguaje principal no se ve

afectada por el número de asteriscos especificados, puesto que no se considera

que los asteriscos formen parte del nombre.

v Siempre que utilice una variable de puntero en una sentencia de SQL, debe dejar

la opción de precompilación del nivel de optimización (OPTLEVEL) en su valor

por omisión, que es 0 (sin optimización). Esto significa que el gestor de bases de

datos no realizará ninguna optimización de la SQLDA.





página 117






Declaración de miembros de datos de clase como variables del

lenguaje principal en aplicaciones de SQL incorporado C++

Puede declarar miembros de datos de clase como variables del lenguaje principal

(pero no clases u objetos en sí mismos). El ejemplo siguiente ilustra el método a

utilizar:


class STAFF

{

private:


char staff_name[20];

short int staff_id;

double staff_salary;


short staff_in_db;

.

.

};

A los miembros de datos sólo se puede acceder directamente en sentencias de SQL

mediante el puntero this implícito proporcionado por el compilador C++ en las

funciones de miembros de clases. No se puede calificar explícitamente una

instancia de un objeto (como, por ejemplo, SELECT name INTO :my_obj.staff_name

...) en una sentencia de SQL.

Si se hace una referencia directa a miembros de datos de clase en sentencias de

SQL, el gestor de bases de datos resuelve la referencia utilizando el puntero this.

Por este motivo, debe dejar la opción de precompilación del nivel de optimización

(OPTLEVEL) en su valor por omisión, que es 0 (sin optimización).

El ejemplo siguiente muestra cómo se pueden utilizar directamente los miembros

de datos de clase que ha declarado como variables del lenguaje principal en una

sentencia de SQL.

class STAFF

{

... public:

... short int hire( void )

{

EXEC SQL INSERT INTO staff ( name,id,salary )

VALUES ( :staff_name, :staff_id, :staff_salary );

staff_in_db = (sqlca.sqlcode == 0);

return sqlca.sqlcode;

}

};

En este ejemplo, los miembros de datos de clase staff_name, staff_id y

staff_salary se utilizan directamente en la sentencia INSERT. Puesto que se han

declarado como variables del lenguaje principal (consulte el primer ejemplo de esta

sección), están calificados de forma implícita para el objeto actual con el puntero

this. En sentencias de SQL también se puede hacer referencia a miembros de datos

a los que no se pueda acceder mediante el puntero this. Esto se logra haciendo una

referencia indirecta a ellos mediante variables del lenguaje principal de puntero o

de referencia.

El ejemplo siguiente muestra un nuevo método, asWellPaidAs, que toma un

segundo objeto, otherGuy. Este método hace referencia a sus miembros

indirectamente, mediante una variable del lenguaje principal de puntero local o de

referencia, puesto que no se puede hacer una referencia directa a sus miembros

dentro de la sentencia de SQL.


short int STAFF::asWellPaidAs( STAFF otherGuy )

{


short &otherID = otherGuy.staff_id

double otherSalary;


EXEC SQL SELECT SALARY INTO :otherSalary

FROM STAFF WHERE id = :otherID;

if( sqlca.sqlcode == 0 )

return staff_salary >= otherSalary;

else

return 0;

}



en la página 86




v “Sentencia INSERT” en Consulta de SQL, Volumen 2

Resolución de ámbito y operaciones de miembro de clase en


No puede utilizar el operador de resolución de ámbito de C++ '::', ni los operadores

de miembro de C y C++ '.' ni '->' en sentencias de SQL incorporado. Se puede

lograr fácilmente lo mismo mediante el uso de variables de puntero o de referencia

locales, que se establecen fuera de la sentencia de SQL, de forma que apunten a la

variable de ámbito que se desee y luego se utilizan dentro de la sentencia de SQL

para hacer referencia a ésta. El ejemplo siguiente muestra el método correcto a

utilizar:


char (& localName)[20] = ::name;


EXEC SQL

SELECT name INTO :localName FROM STAFF

WHERE name = ’Sanders’;


v “Declaración de variables del lenguaje principal como punteros en aplicaciones





Consideraciones sobre EUC en japonés o chino tradicional y

UCS-2 en aplicaciones de SQL incorporado C y C++

Si la página de códigos de la aplicación es EUC en japonés o chino tradicional, o si

la aplicación conecta con una base de datos UCS-2, puede acceder a columnas

GRAPHIC del servidor de bases de datos utilizando las opciones CONVERT o

NOCONVERT y las variables del lenguaje principal de gráficos wchar_t o

sqldbchar, o las SQLDA de entrada/salida. En este apartado, formato DBCS hace

referencia al esquema de codificación de UCS-2 para datos EUC. Considere los

casos siguientes:


v Se utiliza la opción CONVERT

El cliente DB2 convierte los datos gráficos del formato de caracteres amplios a la

página de códigos de la aplicación, y luego a UCS-2, antes de enviar la SQLDA

de entrada al servidor de bases de datos. Los datos gráficos se envían al

servidor de bases de datos identificados por el identificador de página de

códigos de UCS-2. Los datos de tipo carácter mixtos se identifican con el

identificador de página de códigos de la aplicación. Cuando un cliente recupera

datos gráficos de una base de datos, éstos se identifican con el identificador de

página de códigos de UCS-2. El cliente DB2 convierte los datos de UCS-2 a la

página de códigos de la aplicación cliente y luego al formato de caracteres

amplios. Si se utiliza una SQLDA de entrada en lugar de una variable del

lenguaje principal, se requiere al usuario que se asegure de que los datos

gráficos se han codificado utilizando el formato de caracteres amplios. Estos

datos se convertirán a UCS-2 y luego se enviarán al servidor de bases de datos.

Estas conversiones tendrán impacto en el rendimiento.

v Se utiliza la opción NOCONVERT

DB2 supone que los datos se han codificado utilizando UCS-2 y están

identificados por la página de códigos de UCS-2, y no se produce ninguna

conversión. DB2 supone que la variable del lenguaje principal de gráficos se

utiliza simplemente como contenedor. Si no se selecciona la opción

NOCONVERT, los datos gráficos recuperados del servidor de bases de datos se

pasan a la aplicación codificados mediante UCS-2. Las posibles conversiones de

la página de códigos de la aplicación a UCS-2 y de UCS-2 a la página de códigos

de la aplicación son responsabilidad del usuario. Los datos identificados como

UCS-2 se envían al servidor de bases de datos sin que se produzca ninguna

conversión ni alteración.

Para minimizar las conversiones, puede utilizar la opción NOCONVERT y manejar

las conversiones en la aplicación, o bien no utilizar columnas GRAPHIC. Para los

entornos de cliente en que la codificación wchar_t es en Unicode de dos bytes, por

ejemplo en Windows 2000 o AIX versión 5.1 y posteriores, puede utilizar la opción

NOCONVERT y trabajar directamente con UCS-2. En estos casos, la aplicación

debe manejar la diferencia entre las arquitecturas big-endian y little-endian. Con la

opción NOCONVERT, los sistemas de bases de datos DB2 utilizan sqldbchar, que

es siempre un big-endian de dos bytes.

No asigne datos IBM-eucJP/IBM-eucTW CS0 (ASCII de 7 bits) e IBM-eucJP CS2

(Katakana) a variables gráficas de lenguaje principal después de una conversión a

UCS-2 (si se especifica NOCONVERT) ni mediante una conversión al formato de

caracteres amplios (si se especifica CONVERT). Esto es así porque los caracteres de

estos juegos de códigos EUC pasan a tener un solo byte cuando se convierten de

UCS-2 a DBCS de PC.

En general, aunque eucJP y eucTW almacenan los datos gráficos (GRAPHIC) como

UCS-2, los datos GRAPHIC contenidos en estas bases de datos siguen siendo datos

eucJP o eucTW no ASCII. Concretamente, cualquier espacio rellenado en estos

datos GRAPHIC es espacio DBCS (también conocido como espacio ideográfico en

UCS-2, U+3000). Sin embargo, para una base de datos UCS-2, los datos GRAPHIC

pueden contener cualquier carácter UCS-2 y el relleno del espacio se realiza con

espacio UCS-2, U+0020. Tenga presente esta diferencia cuando codifique

aplicaciones para recuperar datos UCS-2 de una base de datos UCS-2, en

comparación con la recuperación de datos UCS-2 de bases de datos eucJP y eucTW.











v “Transferencia de datos en un programa de SQL ejecutado dinámicamente

utilizando una estructura SQLDA” en la página 163

Almacenamiento binario de valores de variables mediante la

cláusula FOR BIT DATA en aplicaciones de SQL incorporado C y

C++

No se debe utilizar el tipo de serie estándar de C o C++, 460, para las columnas

designadas como FOR BIT DATA. El gestor de bases de datos trunca este tipo de

datos cuando se encuentra un carácter nulo. Utilice las estructuras VARCHAR (tipo

de SQL 448) o CLOB (tipo de SQL 408).







Inicialización de variables del lenguaje principal en aplicaciones

de SQL incorporado C y C++

En las secciones declare de C y C++, puede declarar e inicializar varias variables

en una sola línea. Sin embargo, las variables se deben inicializar utilizando el

símbolo ″=″, no mediante paréntesis. El ejemplo siguiente muestra los métodos

correcto e incorrecto de inicialización en una sección de declaración:


short my_short_2 = 5; /* correcto */

short my_short_1(5); /* incorrecto */




en la página 86



Expansión de macros y DECLARE SECTION de aplicaciones de

SQL incorporado C y C++

El precompilador C o C++ no puede procesar directamente ninguna macro de C

utilizada en una declaración dentro de una sección de declaración. En lugar de

esto, en primer lugar se debe preprocesar el archivo fuente mediante un


preprocesador de C externo. Para ello, especifique el mandato exacto para invocar

un preprocesador de C para el precompilador mediante la opción

PREPROCESSOR.

Cuando se especifica la opción PREPROCESSOR, el precompilador procesa en

primer lugar todas las sentencias de SQL INCLUDE, incorporando al archivo

fuente el contenido de todos los archivos a los que se hace referencia en la

sentencia de SQL INCLUDE. A continuación, el precompilador invoca al

preprocesador de C externo, utilizando el mandato que se especifique con el

archivo fuente modificado como entrada. El archivo preprocesado, del cual el

precompilador siempre espera que tenga la extensión .i, se utiliza como el nuevo

archivo fuente para el resto del proceso de precompilación.

Cualquier macro #line generada por el precompilador deja de hacer referencia al

archivo fuente original, pasando a hacerla al archivo preprocesado. Para relacionar

los errores del compilador con el archivo fuente original, mantenga comentarios en

el archivo preprocesado. Le serán de ayuda para localizar diversas secciones de los

archivos fuente originales, incluidos los archivos de cabecera. La opción para

mantener comentarios suele estar disponible en los preprocesadores C y la puede

incluir en el mandato que especifique mediante la opción PREPROCESSOR. No

debe hacer que el preprocesador de C produzca por sí mismo como salida ninguna

macro #line, puesto que se podrían mezclar incorrectamente con las generadas por

el precompilador.

Notas sobre la utilización de la expansión de macros:

1. El mandato que especifique mediante la opción PREPROCESSOR debe incluir

todas las opciones deseadas, pero no el nombre del archivo de entrada. Por

ejemplo, para IBM C en AIX, puede utilizar la opción:

xlC -P -DMYMACRO=1

2. El precompilador espera que el mandato genere un archivo preprocesado con la

extensión .i. Sin embargo, no se puede utilizar la redirección para generar el

archivo preprocesado. Por ejemplo, no se puede utilizar la opción siguiente

para generar un archivo preprocesado:

xlC -E > x.i

3. Los errores que encuentre el preprocesador de C externo se notifican en un

archivo que tiene el nombre correspondiente al archivo fuente original pero con

la extensión .err.

Por ejemplo, puede utilizar la expansión de macros en el código fuente tal como se

indica a continuación:

#define SIZE 3


char a[SIZE+1];

char b[(SIZE+1)*3];

struct

{

short length;

char data[SIZE*6];

} m;

SQL TYPE IS BLOB(SIZE+1) x;

SQL TYPE IS CLOB((SIZE+2)*3) y;

SQL TYPE IS DBCLOB(SIZE*2K) z;


Las declaraciones anteriores se resuelven de la manera siguiente después de

utilizar la opción PREPROCESSOR:



char a[4];

char b[12];

struct

{

short length;

char data[18];

} m;

SQL TYPE IS BLOB(4) x;

SQL TYPE IS CLOB(15) y;

SQL TYPE IS DBCLOB(6144) z;



v “Programas de utilidad de comprobación de errores” en la página 223



48


Soporte de estructuras del lenguaje principal en la sección de

declaración de aplicaciones de SQL incorporado C y C++

Con el soporte de estructuras del lenguaje principal, el precompilador C o C++

permite agrupar las variables del lenguaje principal en una sola estructura del

lenguaje principal. Esta función brinda una nota taquigráfica para hacer referencia

a ese mismo conjunto de variables del lenguaje principal en una sentencia de SQL.

Por ejemplo, se puede utilizar la siguiente estructura del lenguaje principal para

acceder a algunas de las columnas de la tabla STAFF de la base de datos SAMPLE:

struct tag

{

short id;

struct

{

short length;

char data[10];

} name;

struct

{

short years;

double salary;

} info;

} staff_record;

Los campos de una estructura del lenguaje principal pueden ser de cualquiera de

los tipos de variable del lenguaje principal válidos. Los tipos válidos incluyen

todos los tipos numéricos, de carácter y de objetos grande. También se soportan

estructuras del lenguaje principal anidadas hasta 25 niveles. En el ejemplo anterior,

el campo info es una subestructura, mientras que el campo name no lo es, puesto

que representa un campo VARCHAR. Se aplica el mismo principio a LONG

VARCHAR, VARGRAPHIC y LONG VARGRAPHIC. Asimismo, se soportan

punteros a las estructuras del lenguaje principal.

Existen dos maneras de hacer referencia a las variables del lenguaje principal

agrupadas en una estructura del lenguaje principal en una sentencia de SQL:

v Se puede hacer referencia al nombre de la estructura del lenguaje principal en

una sentencia de SQL.


EXEC SQL SELECT id, name, years, salary

INTO :staff_record

FROM staff

WHERE id = 10;

El precompilador convierte la referencia a staff_record en una lista de todos los

campos declarados en la estructura del lenguaje principal, separados por comas.

Cada campo se califica con los nombres de estructura del lenguaje principal de

todos los niveles, a fin de evitar conflictos de denominación con otras variables

del lenguaje principal o campos. Esto es equivalente al método siguiente.

v Se puede hacer referencia a nombres de estructuras del lenguaje principal

completamente calificadas en una sentencia de SQL.


INTO :staff_record.id, :staff_record.name,

:staff_record.info.years, :staff_record.info.salary

FROM staff

WHERE id = 10;

Las referencias a nombres de campos se deben calificar por completo aunque no

existan otras variables del lenguaje principal que tengan el mismo nombre.

También se puede hacer referencia a subestructuras calificadas. En el ejemplo

anterior, se puede utilizar :staff_record.info para sustituir a

:staff_record.info.years, :staff_record.info.salary.

Puesto que una referencia a una estructura del lenguaje principal (primer ejemplo)

es equivalente a una lista de sus campos, separados por comas, existen casos en

que este tipo de referencia puede conducir a un error. Por ejemplo:

EXEC SQL DELETE FROM :staff_record;

Aquí, la sentencia DELETE espera una sola variable del lenguaje principal basada

en caracteres. Si en su lugar se proporciona una estructura del lenguaje principal,

la sentencia tiene como resultado un error durante la precompilación:

SQL0087N La variable del lenguaje principal "staff_record" es una estructura

que se utiliza donde no se permiten referencias a estructuras.

Otros usos de las estructuras del lenguaje principal que pueden ocasionar que se

produzca un error SQL0087N incluyen: PREPARE, EXECUTE IMMEDIATE, CALL,

variables de indicador y referencias a SQLDA. Las estructuras del lenguaje

principal que tengan exactamente un campo están permitidas en estas situaciones,

puesto que constituyen referencias a campos individuales (segundo ejemplo).












Variables de indicador de nulo o de truncamiento y tablas de

indicadores en aplicaciones de SQL incorporado C y C++

Para cada variable del lenguaje principal que pueda recibir valores nulos, declare

variables de indicador como un tipo de datos short.

Una tabla de indicadores es un conjunto de variables de indicador que se

utilizarán con una estructura del lenguaje principal. Se debe declarar como matriz

de enteros cortos. Por ejemplo:

short ind_tab[10];

El ejemplo anterior declara una tabla de indicadores con 10 elementos. El siguiente

ejemplo muestra la manera en que se puede utilizar en una sentencia de SQL:


INTO :staff_record INDICATOR :ind_tab

FROM staff

WHERE id = 10;

A continuación se lista cada campo de la estructura del lenguaje principal con la

variable de indicador correspondiente en la tabla:

staff_record.id ind_tab[0]

staff_record.name ind_tab[1]

staff_record.info.years ind_tab[2]

staff_record.info.salary ind_tab[3]

Nota: En una sentencia de SQL no se puede hacer referencia, de forma individual,

a un elemento de una tabla de indicadores, por ejemplo ind_tab[1]. La

palabra clave INDICATOR es opcional. No es necesario que el número de

campos de estructura y de indicadores coincida; los indicadores de más no

se utilizan ni tampoco los campos de más que no tienen indicadores

asignados.

En lugar de una tabla de indicadores, también se puede utilizar una variable de

indicador escalar para proporcionar un indicador para el primer campo de la

estructura del lenguaje principal. Esto equivale a tener una tabla de indicadores

con un solo elemento. Por ejemplo:

short scalar_ind;


INTO :staff_record INDICATOR :scalar_ind

FROM staff

WHERE id = 10;

Si se especifica una tabla de indicadores junto con una variable del lenguaje

principal en lugar de una estructura del lenguaje principal, sólo se utilizará el

primer elemento de la tabla de indicadores, por ejemplo ind_tab[0]:

EXEC SQL SELECT id

INTO :staff_record.id INDICATOR :ind_tab

FROM staff

WHERE id = 10;

Si se declara una matriz de enteros cortos en una estructura del lenguaje principal:


struct tag

{

short i[2];

} test_record;

La matriz se expandirá en sus elementos cuando se haga referencia a test_record

en una sentencia de SQL, haciendo que :test_record sea equivalente a

:test_record.i[0], :test_record.i[1].





en la página 86





Series terminadas en nulo en aplicaciones de SQL incorporado

C y C++

Las series terminadas en nulo de C y C++ tienen su propio SQLTYPE (460/461

para caracteres y 468/469 para gráficos).

Las series terminadas en nulo de C y C++ se manejan de forma distinta en función

del valor de la opción LANGLEVEL del precompilador. Si se especifica una

variable del lenguaje principal con uno de estos valores SQLTYPE y la longitud

declarada n dentro de una sentencia de SQL y el número de bytes de datos (para

tipos de carácter) o de caracteres de doble byte (para tipos gráficos) es k, sucede lo

siguiente:

v Si la opción LANGLEVEL del mandato PREP es SAA1 (valor por omisión):

Para la salida:

Si... Sucede que...

k > n Se mueven n caracteres a la variable del lenguaje

principal de destino, SQLWARN1 se establece en

'W' y SQLCODE es 0 (SQLSTATE 01004). No se

coloca ningún terminador nulo en la serie. Si se

ha especificado una variable de indicador con la

variable del lenguaje principal, el valor de la

variable de indicador se establece en k.

k = n Se mueven k caracteres a la variable del lenguaje

principal de destino, SQLWARN1 se establece en

'N' y SQLCODE es 0 (SQLSTATE 01004). No se

coloca ningún terminador nulo en la serie. Si se



variable de indicador se establece en 0.

k < n Se mueven k caracteres a la variable del lenguaje

principal de destino y se coloca un carácter nulo

en el carácter k + 1. Si se ha especificado una


variable de indicador con la variable del lenguaje

principal, el valor de la variable de indicador se

establece en 0.

Para entrada: Cuando el gestor de bases de datos encuentre una variable del

lenguaje principal de entrada que tiene uno de estos valores

SQLTYPE y no finaliza por un terminador nulo, supondrá que el

carácter n+1 contendrá el carácter terminador nulo.v Si la opción LANGLEVEL del mandato PREP es MIA:

Para salida:

Si... Sucede que...

k >= n Se mueven n - 1 caracteres a la variable del

lenguaje principal de destino, SQLWARN1 se

establece en 'W' y SQLCODE es 0 (SQLSTATE

01004). El carácter número n se establece como

terminador nulo. Si se ha especificado una



establece en k.

k + 1 = n Se mueven k caracteres a la variable del lenguaje

principal de destino y se coloca el terminador

nulo en el carácter n. Si se ha especificado una



establece en 0.

k + 1 < n Se mueven k caracteres a la variable del lenguaje

principal de destino, se añaden n - k -1 blancos a

la derecha, a partir del carácter k + 1, y luego se

coloca el terminador nulo en el carácter n. Si se



variable de indicador se establece en 0.

Para entrada: Cuando el gestor de bases de datos encuentre una variable del

lenguaje principal de entrada que tenga uno de estos valores

SQLTYPE y no finalice por un carácter nulo, se devolverá

SQLCODE -302 (SQLSTATE 22501).

Si se especifica en cualquier otro contexto de SQL, una variable del lenguaje

principal con SQLTYPE 460 y longitud n se trata como el tipo de datos VARCHAR

con longitud n, tal como se ha definido anteriormente. Si se especifica en cualquier

otro contexto de SQL, una variable del lenguaje principal con SQLTYPE 468 y

longitud n se trata como el tipo de datos VARGRAPHIC con longitud n, tal como

se ha definido anteriormente.








Variables del lenguaje principal en COBOL

Variables del lenguaje principal en COBOL

Las variables del lenguaje principal son variables del lenguaje COBOL a las que se

hace referencia en las sentencias de SQL. Permiten a una aplicación intercambiar

datos con el gestor de bases de datos. Una vez que se ha precompilado la

aplicación, el compilador utiliza las variables del lenguaje principal como cualquier

otra variable de COBOL. Cuando denomine, declare y utilice variables del lenguaje

principal, siga las normas descritas en los apartados siguientes.







Nombres de variables del lenguaje principal en COBOL


declarado para éstas. Se aplican las normas siguientes:

v Especifique nombres de variables con una longitud máxima de 255 caracteres.

v Empiece los nombres de variables con prefijos que no sean SQL, sql, DB2 ni db2,

que están reservados para uso del sistema.

v Los elementos FILLER que utilizan las sintaxis de declaración descritas a

continuación están permitidos en las declaraciones de variables del lenguaje

principal de grupos y el precompilador los pasará por alto. Sin embargo, si se

utiliza FILLER más de una vez dentro de una sección DECLARE de SQL, el

precompilador fallará. No se pueden incluir elementos FILLER en declaraciones

VARCHAR, LONG VARCHAR, VARGRAPHIC ni LONG VARGRAPHIC.

v Puede utilizar guiones en los nombres de variables del lenguaje principal.

SQL interpreta un guión encerrado entre espacios como un operador de resta.

Utilice guiones sin espacios en los nombres de variables del lenguaje principal.

v La cláusula REDEFINES está permitida en las declaraciones de variables del

lenguaje principal.

v Las declaraciones de nivel 88 están permitidas en la sección de declaración de

variables del lenguaje principal, pero se pasan por alto.







v “Declaración de variables del lenguaje principal de tipo carácter de longitud fija

y longitud variable en aplicaciones de SQL incorporado COBOL” en la página

123

v “Declaración de variables del lenguaje principal de tipo graphic de longitud fija


125



object) en aplicaciones de SQL incorporado COBOL” en la página 126


grande (large object locator) en aplicaciones de SQL incorporado COBOL” en la

página 127


SQL incorporado COBOL” en la página 122


aplicaciones de SQL incorporado COBOL


declaraciones de variables del lenguaje principal. Esta sección alerta al

precompilador acerca de las variables del lenguaje principal a las que se puede

hacer referencia en sentencias de SQL posteriores. Por ejemplo:


77 dept pic s9(4) comp-5.

01 userid pic x(8).

01 passwd.


El precompilador COBOL sólo reconoce un subconjunto de las declaraciones

válidas de COBOL.









123



125




grande (large object locator) en aplicaciones de SQL incorporado COBOL” en la

página 127




de SQL incorporado COBOL

A continuación se muestra un ejemplo de sección de declaración de SQL con una

variable del lenguaje principal declarada para los tipos de datos SQL soportados.


*

01 age PIC S9(4) COMP-5. /* SQL tipo 500 */

01 divis PIC S9(9) COMP-5. /* SQL tipo 496 */

01 salary PIC S9(6)V9(3) COMP-3. /* SQL tipo 484 */


01 bonus USAGE IS COMP-1. /* SQL tipo 480 */

01 wage USAGE IS COMP-2. /* SQL tipo 480 */

01 nm PIC X(5). /* SQL tipo 452 */

01 varchar.

49 leng PIC S9(4) COMP-5. /* SQL tipo 448 */

49 strg PIC X(14). /* SQL tipo 448 */

01 longvchar.

49 len PIC S9(4) COMP-5. /* SQL tipo 456 */

49 str PIC X(6027). /* SQL tipo 456 */

01 MY-CLOB USAGE IS SQL TYPE IS CLOB(1M). /* SQL tipo 408 */

01 MY-CLOB-LOCATOR USAGE IS SQL TYPE IS CLOB-LOCATOR. /* SQL tipo 964 */

01 MY-CLOB-FILE USAGE IS SQL TYPE IS CLOB-FILE. /* SQL tipo 920 */

01 MY-BLOB USAGE IS SQL TYPE IS BLOB(1M). /* SQL tipo 404 */

01 MY-BLOB-LOCATOR USAGE IS SQL TYPE IS BLOB-LOCATOR. /* SQL tipo 960 */

01 MY-BLOB-FILE USAGE IS SQL TYPE IS BLOB-FILE. /* SQL tipo 916 */

01 MY-DBCLOB USAGE IS SQL TYPE IS DBCLOB(1M). /* SQL tipo 412 */

01 MY-DBCLOB-LOCATOR USAGE IS SQL TYPE IS DBCLOB-LOCATOR. /* SQL tipo 968 */

01 MY-DBCLOB-FILE USAGE IS SQL TYPE IS DBCLOB-FILE. /* SQL tipo 924 */

01 MY-PICTURE PIC G(16000) USAGE IS DISPLAY-1. /* SQL tipo 464 */

01 dt PIC X(10). /* SQL tipo 384 */

01 tm PIC X(8). /* SQL tipo 388 */

01 tmstmp PIC X(26). /* SQL tipo 392 */

01 wage-ind PIC S9(4) COMP-5. /* SQL tipo 464 */

*








Tipos de datos BINARY/COMP-4 en aplicaciones de SQL

incorporado COBOL

El precompilador COBOL de DB2 da soporte al uso de los tipos de datos BINARY,

COMP y COMP-4 dondequiera que estén permitidas las variables del lenguaje

principal y los indicadores, siempre que el compilador COBOL de destino vea (o se

pueda hacer que vea) los tipos de datos BINARY, COMP o COMP-4 como

equivalentes al tipo de datos COMP-5. En los ejemplos proporcionados, estas

variables del lenguaje principal e indicadores se muestran con el tipo COMP-5. Los

compiladores de destino soportados por DB2 que tratan COMP, COMP-4, BINARY

COMP y COMP-5 como equivalentes son:

v IBM COBOL Set para AIX

v Micro Focus COBOL para AIX









Variables SQLSTATE y SQLCODE en aplicaciones de SQL

incorporado COBOL

Cuando se utiliza la opción de precompilación LANGLEVEL con el valor SQL92E,

se pueden incluir las dos declaraciones siguientes como variables del lenguaje

principal:


01 SQLSTATE PIC X(5).

01 SQLCODE PIC S9(9) USAGE COMP.

.

.

.


Si no se especifica ninguna de ellas, se supone la declaración SQLCODE durante el

paso de precompilación. Las variables SQLCODE y SQLSTATE se pueden declarar

utilizando el nivel 01 (como se ha mostrado anteriormente) o el nivel 77. Observe

que, si se utiliza esta opción, no se debe especificar la sentencia INCLUDE SQLCA.

Para las aplicaciones formadas por varios archivos fuente, las declaraciones

SQLCODE y SQLSTATE se pueden incluir en cada uno de los archivos fuente, tal

como en el ejemplo anterior.








A continuación se muestra la sintaxis de las variables numéricas del lenguaje

principal.

��

01

77

nombre-variable

PICTURE

PIC

IS

serie-imagen

�

� (1)

COMP-3

IS

COMPUTATIONAL-3

USAGE

COMP-5

COMPUTATIONAL-5

.

IS

VALUE

valor

��

Notas:

1 Una alternativa de COMP-3 es PACKED-DECIMAL.

Coma flotante


��

01

77

nombre-variable

IS

USAGE

(1)

COMPUTATIONAL-1

COMP-1

(2)

COMPUTATIONAL-2

COMP-2

�

� IS

VALUE

valor

. ��

Notas:

1 REAL (SQLTYPE 480), Longitud 4

2 DOUBLE (SQLTYPE 480), Longitud 8

Consideraciones sobre las variables numéricas del lenguaje principal:

1. Serie-imagen debe tener uno de los formatos siguientes:

v S9(m)V9(n)

v S9(m)V

v S9(m)2. Los nueves se pueden expandir (por ejemplo, ″S999″ en lugar de S9(3)″)

3. m y n deben ser enteros positivos.








de longitud fija y longitud variable en aplicaciones de SQL

incorporado COBOL

A continuación se muestra la sintaxis de las variables de tipo carácter del lenguaje

principal.

Longitud fija

��

01

77

nombre-variable

PICTURE

PIC

IS

serie-imagen

�

� IS

VALUE

valor

. ��

Longitud variable

�� 01 nombre-variable . ��


��

49

identificador-1

PICTURE

PIC

IS

S9(4)

�

� COMP-5

IS

COMPUTATIONAL-5

USAGE

IS

VALUE

valor

. ��

��

49

identificador-2

PICTURE

PIC

IS

serie-imagen

�

� IS

VALUE

valor

. ��

Consideración sobre las variables del lenguaje principal de tipo carácter:

1. Serie-imagen debe tener el formato X(m). Como alternativa, se pueden expandir

las X (por ejemplo, ″XXX″ en lugar de ″X(3)″).

2. m va de 1 a 254 para las series de longitud fija.

3. m va de 1 a 32 700 para las series de longitud variable.

4. Si m es mayor que 32 672, la variable del lenguaje principal se tratará como una

serie LONG VARCHAR y su uso puede estar restringido.

5. Utilice X y 9 como caracteres de imagen en cualquier cláusula PICTURE. No

están permitidos otros caracteres.

6. Las series de longitud variable constan de un elemento de longitud y un

elemento de valor. Puede utilizar nombres aceptables de COBOL para el

elemento de longitud y para el elemento de serie. No obstante, haga referencia

a las series de longitud variable por el nombres colectivo en las sentencias de

SQL.

7. En una sentencia CONNECT, como por ejemplo la que se muestra a

continuación, a las variables del lenguaje principal de serie de caracteres en

COBOL dbname y userid se les eliminarán los blancos de cola antes del proceso:

EXEC SQL CONNECT TO :dbname USER :userid USING :p-word

END-EXEC.

Sin embargo, y puesto que los espacios en blanco pueden ser significativos en

las contraseñas, la variable del lenguaje principal p-word se debe declarar como

un elemento de datos VARCHAR, de forma que la aplicación pueda indicar

explícitamente la longitud significativa de la contraseña para la sentencia

CONNECT, del modo siguiente:


01 dbname PIC X(8).

01 userid PIC X(8).

01 p-word.

49 L PIC S9(4) COMP-5.

49 D PIC X(18).


PROCEDURE DIVISION.

MOVE "sample" TO dbname.

MOVE "userid" TO userid.


MOVE "password" TO D OF p-word.

MOVE 8 TO L of p-word.

EXEC SQL CONNECT TO :dbname USER :userid USING :p-word

END-EXEC.



página 58






Declaración de variables del lenguaje principal de tipo graphic


incorporado COBOL

A continuación se muestra la sintaxis de las variables de tipo graphic del lenguaje

principal.

Longitud fija

��

01

77

nombre-variable

PICTURE

PIC

IS

serie-imagen

USAGE

�

� IS

DISPLAY-1

IS

VALUE

valor

.

��

Longitud variable

�� 01 nombre-variable . ��

��

49

identificador-1

PICTURE

PIC

IS

S9(4)

�

� COMP-5

IS

COMPUTATIONAL-5

USAGE

IS

VALUE

valor

. ��

��

49

identificador-2

PICTURE

PIC

IS

serie-imagen

USAGE

�


� IS

DISPLAY-1

IS

VALUE

valor

.

��

Consideraciones sobre las variables gráficas del lenguaje principal:

1. Serie-imagen debe tener el formato G(m). Como alternativa, se pueden expandir

las G (por ejemplo, ″GGG″ en lugar de ″G(3)″).

2. m va de 1 a 127 para las series de longitud fija.

3. m va de 1 a 16 350 para las series de longitud variable.

4. Si m es mayor que 16 336, la variable del lenguaje principal se tratará como una

serie LONG VARGRAPHIC y su uso puede estar restringido.








grande (large object) en aplicaciones de SQL incorporado

COBOL


de objeto grande (LOB) en COBOL.

�� 01 nombre-variable

USAGE

IS

SQL TYPE IS BLOB

CLOB

DBCLOB

�

� ( longitud ) .

K

M

G

��


1. Para BLOB y CLOB 1 <= longitud-lob <= 2 147 483 647.

2. Para DBCLOB 1 <= longitud-lob <= 1 073 741 823.

3. SQL TYPE IS, BLOB, CLOB, DBCLOB, K, M, G se pueden especificar en

mayúsculas, en minúsculas o en una mezcla de ambas.

4. No se permite la inicialización dentro de la declaración LOB.

5. El nombre de la variable del lenguaje principal es el prefijo de LENGTH y

DATA en el código generado por el precompilador.

Ejemplo de BLOB:

La declaración:

01 MY-BLOB USAGE IS SQL TYPE IS BLOB(2M).



01 MY-BLOB.

49 MY-BLOB-LENGTH PIC S9(9) COMP-5.

49 MY-BLOB-DATA PIC X(2097152).

Ejemplo de CLOB:

La declaración:

01 MY-CLOB USAGE IS SQL TYPE IS CLOB(125M).


01 MY-CLOB.

49 MY-CLOB-LENGTH PIC S9(9) COMP-5.

49 MY-CLOB-DATA PIC X(131072000).

Ejemplo de DBCLOB:

La declaración:

01 MY-DBCLOB USAGE IS SQL TYPE IS DBCLOB(30000).


01 MY-DBCLOB.

49 MY-DBCLOB-LENGTH PIC S9(9) COMP-5.

49 MY-DBCLOB-DATA PIC G(30000) DISPLAY-1.











de localizador de objeto grande (LOB) en COBOL.


USAGE

IS

SQL TYPE IS BLOB-LOCATOR

CLOB-LOCATOR

DBCLOB-LOCATOR

. ��


LOB:

1. SQL TYPE IS, BLOB-LOCATOR, CLOB-LOCATOR, DBCLOB-LOCATOR se

pueden especificar en mayúsculas, en minúsculas o en una mezcla de ambas.

2. No se permite la inicialización de localizadores.

Ejemplo de localizador de BLOB (existen otros tipos de localizadores de LOB

parecidos):

La declaración:

01 MY-LOCATOR USAGE SQL TYPE IS BLOB-LOCATOR.



01 MY-LOCATOR PIC S9(9) COMP-5.






Declaración de variables del lenguaje principal de referencia de

archivos aplicaciones de SQL incorporado COBOL


de referencia de archivos en COBOL.


USAGE

IS

SQL TYPE IS BLOB-FILE

CLOB-FILE

DBCLOB-FILE

. ��

v SQL TYPE IS, BLOB-FILE, CLOB-FILE, DBCLOB-FILE se pueden especificar en


Ejemplo de referencia de archivos BLOB (existen otros tipos de LOB parecidos):

La declaración:

01 MY-FILE USAGE IS SQL TYPE IS BLOB-FILE.


01 MY-FILE.

49 MY-FILE-NAME-LENGTH PIC S9(9) COMP-5.

49 MY-FILE-DATA-LENGTH PIC S9(9) COMP-5.

49 MY-FILE-FILE-OPTIONS PIC S9(9) COMP-5.

49 MY-FILE-NAME PIC X(255).





Agrupación de elementos de datos utilizando REDEFINES en


Cuando declare variables del lenguaje principal, puede utilizar la cláusula

REDEFINES. Si declara un miembro de un elemento de datos de grupo con la

cláusula REDEFINES y se hace referencia a ese elemento de datos de grupo como

un todo en una sentencia de SQL, los elementos subordinados que contienen la

cláusula REDEFINES no se expanden. Por ejemplo:

01 foo.

10 a pic s9(4) comp-5.

10 a1 redefines a pic x(2).

10 b pic x(10).

La referencia a foo en una sentencia de SQL es como sigue:

... INTO :foo ...

La sentencia anterior es equivalente a:


... INTO :foo.a, :foo.b ...

Es decir, el elemento subordinado a1, que se declara con la cláusula REDEFINES,

no se expande automáticamente en estas situaciones. Si a1 es inequívoco, se puede

hacer una referencia explícita a un subordinado que tenga una cláusula

REDEFINES en una sentencia de SQL, del modo siguiente:

... INTO :foo.a1 ...

o

... INTO :a1 ...




UCS-2 para aplicaciones de SQL incorporado COBOL

Los datos gráficos enviados desde una aplicación que se ejecuta bajo un juego de

códigos eucJp o eucTW, o se conecta a una base de datos UCS-2, se identifican con

el identificador de la página de códigos UCS-2. La aplicación debe convertir una

serie de caracteres gráficos a UCS-2 antes de enviarla al servidor de bases de datos.

Del mismo modo, los datos gráficos recuperados de una base de datos UCS-2 por

una aplicación, o de cualquier base de datos por una aplicación que se ejecute bajo

una página de códigos EUC eucJP o eucTW, se codifican utilizando UCS-2. Esto

requiere que la aplicación realice internamente una conversión de UCS-2 a la

página de códigos de la aplicación, a menos que se vayan a presentar datos UCS-2

al usuario.

La aplicación es responsable de convertir a UCS-2 y desde UCS-2, puesto que esta

conversión se debe llevar a cabo antes de copiar los datos a la SQLDA o desde

esta. DB2 Database para Linux, UNIX y Windows no suministra ninguna rutina de

conversión que resulte accesible para la aplicación. En cambio, se deben utilizar las

llamadas del sistema disponibles desde el sistema operativo. En el caso de una

base de datos UCS-2, también puede considerar la posibilidad de utilizar las

funciones escalares VARCHAR y VARGRAPHIC.





v “Función escalar VARCHAR” en Consulta de SQL, Volumen 1

v “Función escalar VARGRAPHIC” en Consulta de SQL, Volumen 1



125

Almacenamiento binario de valores de variables mediante la

cláusula FOR BIT DATA en aplicaciones de SQL incorporado

COBOL

Determinadas columnas de bases de datos se pueden declarar FOR BIT DATA.

Estas columnas, que generalmente contienen caracteres, se utilizan para contener

información binaria. Los tipos de datos CHAR(n), VARCHAR, LONG VARCHAR y


BLOB son los tipos de variable del lenguaje principal de COBOL que pueden

contener datos binarios. Utilice estos tipos de datos cuando trabaje con columnas

que tengan el atributo FOR BIT DATA.






Soporte de estructuras del lenguaje principal en la sección de

declaración de aplicaciones de SQL incorporado COBOL

El precompilador COBOL soporta declaraciones de elementos de datos de grupos

en la sección de declaración de variables del lenguaje principal. Entre otras cosas,

esto proporciona un sistema taquigráfico para hacer referencia a un conjunto de

elementos de datos elementales en una sentencia de SQL. Por ejemplo, se puede

utilizar el siguiente elemento de datos de grupo para acceder a algunas de las

columnas de la tabla STAFF de la base de datos SAMPLE:

01 staff-record.

05 staff-id pic s9(4) comp-5.

05 staff-name.

49 l pic s9(4) comp-5.

49 d pic x(9).

05 staff-info.

10 staff-dept pic s9(4) comp-5.

10 staff-job pic x(5).

Los elementos de datos de grupos de la sección de declaración pueden tener, como

elementos de datos subordinados, cualquiera de los tipos válidos de variable del

lenguaje principal descritos anteriormente. Esto incluye todos los tipos de datos

numéricos y de tipo carácter, así como los tipos de objeto grande. Los elementos de

datos de grupos se pueden anidar hasta un máximo de 10 niveles. Observe que

debe declarar los tipos de caracteres VARCHAR con los elementos subordinados al

nivel 49, tal como en el ejemplo anterior. Si no están al nivel 49, VARCHAR se

trata como elemento de datos de grupos con dos subordinados y está sujeto a las

normas de declaración y utilización de elementos de datos de grupos. En el

ejemplo anterior, staff-info es un elemento de datos de grupos, mientras que

staff-name es VARCHAR. Se aplica el mismo principio a LONG VARCHAR,

VARGRAPHIC y LONG VARGRAPHIC. Puede declarar elementos de datos de

grupos a cualquier nivel entre 02 y 49.

Puede utilizar elementos de datos de grupos y los subordinados de los mismos de

cuatro maneras:

Método 1.

Se puede hacer referencia al grupo entero como una sola variable del lenguaje

principal en una sentencia de SQL:

EXEC SQL SELECT id, name, dept, job

INTO :staff-record

FROM staff WHERE id = 10 END-EXEC.

El precompilador convierte la referencia a staff-record en una lista de todos los

elementos subordinados declarados dentro de staff-record, separados por comas.


Cada elemento elemental se califica con los nombres de grupo de todos los niveles,

a fin de evitar conflictos de denominación con otros elementos. Esto es equivalente

al método siguiente.

Método 2.

La segunda manera de utilizar elementos de datos de grupos:


INTO

:staff-record.staff-id,

:staff-record.staff-name,

:staff-record.staff-info.staff-dept,

:staff-record.staff-info.staff-job


Nota: La referencia a staff-id se califica con su nombre de grupo utilizando el

prefijo staff-record., y no staff-id de staff-record como se hace en

COBOL puro.

Suponiendo que no existen otras variables del lenguaje principal que tengan los

mismos nombres que los subordinados de staff-record, la sentencia anterior

también se puede codificar como en el método 3, eliminando la calificación

explícita de grupo.

Método 3.

Aquí, se hace referencia a los elementos subordinados de la forma típica de

COBOL, sin calificarlos con su elemento de grupo concreto:


INTO

:staff-id,

:staff-name,

:staff-dept,

:staff-job


Como en COBOL puro, este método resulta aceptable para el precompilador

siempre que un elemento subordinado determinado se pueda calificar de forma

exclusiva. Por ejemplo, si staff-job aparece más de una vez en un grupo, el

precompilador emite un error indicando que se ha producido una referencia

ambigua:

SQL0088N La variable del lenguaje principal "staff-job" es ambigua.

Método 4.

Para resolver la referencia ambigua, puede utilizar una calificación parcial del

elemento subordinado, por ejemplo:


INTO

:staff-id,

:staff-name,

:staff-info.staff-dept,

:staff-info.staff-job


Puesto que una referencia a un solo elemento de grupo, como en el método 1, es

equivalente a una lista de sus subordinados, separados por comas, existen casos en

que este tipo de referencia conduce a un error. Por ejemplo:


EXEC SQL CONNECT TO :staff-record END-EXEC.

Aquí, la sentencia CONNECT espera una sola variable del lenguaje principal

basada en caracteres. Proporcionando en su lugar el elemento de datos de grupos

staff-record, la variable del lenguaje principal tiene como resultado el error de

precompilación siguiente:

SQL0087N La variable del lenguaje principal "staff-record" es una estructura

que se utiliza donde no se permiten referencias a estructuras.

Otros usos de los elementos de grupos que pueden ocasionar que se produzca un

error SQL0087N incluyen: PREPARE, EXECUTE IMMEDIATE, CALL, variables de

indicador y referencias a SQLDA. Los grupos que sólo tienen un subordinado

están permitidos en ambas situaciones, puesto que se trata de referencias a

subordinados individuales, como en los métodos 2, 3 y 4 anteriores.










123

Tablas de variables de indicador de nulo y de indicador de nulo

o de truncamiento en aplicaciones de SQL incorporado COBOL

Las variables de indicador de nulo se deben declarar con tipo de datos PIC S9(4)

COMP-5.

El precompilador COBOL da soporte a la declaración de tablas de variables de

indicador de nulo (denominadas tablas de indicadores), que es conveniente utilizar

con elementos de datos de grupos. Se declaran del modo siguiente:

01 <indicator-table-name>.

05 <indicator-name> pic s9(4) comp-5

occurs <table-size> times.

Por ejemplo:

01 staff-indicator-table.

05 staff-indicator pic s9(4) comp-5

occurs 7 times.

Esta tabla de indicadores se puede utilizar eficazmente con el primer formato de

referencia de elementos de grupos indicado anteriormente:


INTO :staff-record :staff-indicator


Aquí, el precompilador detecta que staff-indicator se ha declarado como tabla

de indicadores y la expande en referencias a indicadores individuales cuando

procesa la sentencia de SQL. staff-indicator(1) se asocia a staff-id de

staff-record, staff-indicator(2) se asocia a staff-name de staff-record, y así

sucesivamente.


Nota: Si en la tabla de indicadores existen k entradas de indicador más que

subordinados tiene el elemento de datos (por ejemplo, si staff-indicator

tiene 10 entradas, haciendo que k=6), se pasan por alto las k entradas de

más que se encuentran al final de la tabla de indicadores. Del mismo modo,

si hay k entradas de indicador menos que subordinados, los k últimos

subordinados del elemento de grupo no tienen asociado ningún indicador.

Tenga en cuenta que puede hacer referencia a elementos individuales en una tabla de

indicadores en una sentencia de SQL.







Variables del lenguaje principal en FORTRAN

Variables del lenguaje principal en FORTRAN

Las variables del lenguaje principal son variables del lenguaje FORTRAN a las que

se hace referencia en sentencias de SQL. Permiten a una aplicación intercambiar



otra variable de FORTRAN. Cuando denomine, declare y utilice variables del

lenguaje principal, siga las normas descritas en los apartados siguientes.









SQL incorporado FORTRAN


declarado para éstas. Se aplican las sugerencias siguientes:

v Especifique nombres de variables con una longitud máxima de 255 caracteres.

v Empiece los nombres de variables con prefijos que no sean SQL, sql, DB2 ni db2,

que están reservados para uso del sistema.






y longitud variable en aplicaciones de SQL incorporado FORTRAN” en la

página 136





object) en aplicaciones de SQL incorporado FORTRAN” en la página 138


grande (large object locator) en aplicaciones de SQL incorporado FORTRAN” en

la página 139


SQL incorporado FORTRAN” en la página 135


aplicaciones de SQL incorporado FORTRAN


declaraciones de variables del lenguaje principal. Esto alerta al precompilador

acerca de las variables del lenguaje principal a las que se puede hacer referencia en

sentencias de SQL posteriores.

El precompilador FORTRAN sólo reconoce un subconjunto de declaraciones de

FORTRAN válidas como declaraciones de variables del lenguaje principal válidas.

Estas declaraciones definen variables numéricas o de tipo carácter. Una variable

numérica del lenguaje principal se puede utilizar como variable de entrada o de

salida para cualquier valor numérico de entrada o salida de SQL. Una variable del

lenguaje principal de tipo carácter se puede utilizar como variable de entrada o de

salida para cualquier valor de tipo carácter, de fecha, de hora o de indicación de la

hora, de entrada o salida de SQL. El programador se tiene que asegurar de que las

variables de salida sean lo suficientemente largas como para contener los valores

que van a recibir.






y longitud variable en aplicaciones de SQL incorporado FORTRAN” en la

página 136






grande (large object locator) en aplicaciones de SQL incorporado FORTRAN” en

la página 139


SQL incorporado FORTRAN” en la página 135


de SQL incorporado FORTRAN

A continuación se muestra un ejemplo de sección de declaración de SQL con una

variable del lenguaje principal declarada para cada tipo de datos soportado:


EXEC SQL BEGIN DECLARE SECTION

INTEGER*2 AGE /26/ /* SQL tipo 500 */

INTEGER*4 DEPT /* SQL tipo 496 */

REAL*4 BONUS /* SQL tipo 480 */

REAL*8 SALARY /* SQL tipo 480 */

CHARACTER MI /* SQL tipo 452 */

CHARACTER*112 ADDRESS /* SQL tipo 452 */

SQL TYPE IS VARCHAR (512) DESCRIPTION /* SQL tipo 448 */

SQL TYPE IS VARCHAR (32000) COMMENTS /* SQL tipo 448 */

SQL TYPE IS CLOB (1M) CHAPTER /* SQL tipo 408 */

SQL TYPE IS CLOB_LOCATOR CHAPLOC /* SQL tipo 964 */

SQL TYPE IS CLOB_FILE CHAPFL /* SQL tipo 920 */

SQL TYPE IS BLOB (1M) VIDEO /* SQL tipo 404 */

SQL TYPE IS BLOB_LOCATOR VIDLOC /* SQL tipo 960 */

SQL TYPE IS BLOB_FILE VIDFL /* SQL tipo 916 */

CHARACTER*10 DATE /* SQL tipo 384 */

CHARACTER*8 TIME /* SQL tipo 388 */

CHARACTER*26 TIMESTAMP /* SQL tipo 392 */

INTEGER*2 WAGE_IND /* SQL tipo 500 */








Variables SQLSTATE y SQLCODE en aplicaciones de SQL

incorporado FORTRAN

Cuando se utiliza la opción de precompilación LANGLEVEL con el valor SQL92E,

se pueden incluir las dos declaraciones siguientes como variables del lenguaje

principal:


CHARACTER*5 SQLSTATE

INTEGER SQLCOD

.

.

.


Se supone la declaración SQLCOD durante el paso de precompilación. La variable

denominada SQLSTATE también puede ser SQLSTA. Observe que, si se utiliza esta

opción, no se debe especificar la sentencia INCLUDE SQLCA.

Para aplicaciones que contienen varios archivos fuente, se pueden incluir las

declaraciones de SQLCOD y SQLSTATE en cada archivo fuente, tal como se ha

mostrado anteriormente.






A continuación se muestra la sintaxis de las variables numéricas del lenguaje

principal en FORTRAN.


��

INTEGER*2

INTEGER*4

REAL*4

REAL *8

DOUBLE PRECISION

�

,

nombrevar

/ valor-inicial /

��

Consideraciones sobre las variables numéricas del lenguaje principal:

1. REAL*8 y DOUBLE PRECISION son equivalentes.

2. Utilice una E en lugar de una D como indicador de exponente para las

constantes REAL*8.










incorporado FORTRAN

A continuación se muestra la sintaxis de las variables de tipo carácter de longitud

fija del lenguaje principal.

Longitud fija

Sintaxis de las variables del lenguaje principal de tipo carácter en FORTRAN:

Longitud fija

��

�

,

CHARACTER

nombrevar

*n

/ valor-inicial /

��

A continuación se muestra la sintaxis de las variables de tipo carácter de longitud

variable del lenguaje principal.

Longitud variable

��

�

,

SQL TYPE IS VARCHAR

(longitud)

nombrevar

��

Consideraciones sobre variables del lenguaje principal de tipo carácter:

1. *n tiene un valor máximo de 254.

2. Si la longitud está entre 1 y 32 672, ambos inclusive, la variable del lenguaje

principal es de tipo VARCHAR(SQLTYPE 448).

3. Si la longitud está entre 32 673 y 32 700, ambos inclusive, la variable del

lenguaje principal es de tipo LONG VARCHAR(SQLTYPE 456).


4. No está permitida la inicialización de variables del lenguaje principal

VARCHAR y LONG VARCHAR dentro de la declaración.

Ejemplo de VARCHAR:

La declaración:

sql type is varchar(1000) my_varchar


character my_varchar(1000+2)

integer*2 my_varchar_length

character my_varchar_data(1000)

equivalence( my_varchar(1),

+ my_varchar_length )

equivalence( my_varchar(3),

+ my_varchar_data )

La aplicación puede manipular tanto my_varchar_length como my_varchar_data;

por ejemplo, para establecer o examinar el contenido de la variable del lenguaje

principal. El nombre base (en este caso, my_varchar), se utiliza en las sentencias de

SQL para hacer referencia a la VARCHAR como un todo.

Ejemplo de LONG VARCHAR:

La declaración:

sql type is varchar(10000) my_lvarchar


character my_lvarchar(10000+2)

integer*2 my_lvarchar_length

character my_lvarchar_data(10000)

equivalence( my_lvarchar(1),

+ my_lvarchar_length )

equivalence( my_lvarchar(3),

+ my_lvarchar_data )

La aplicación puede manipular tanto my_lvarchar_length como my_lvarchar_data;

por ejemplo, para establecer o examinar el contenido de la variable del lenguaje

principal. El nombre base (en este caso, my_lvarchar) se utiliza en las sentencias de

SQL para hacer referencia a la LONG VARCHAR como un todo.

Nota: En una sentencia CONNECT, como por ejemplo la que se muestra a

continuación, a las variables del lenguaje principal de serie de caracteres en

FORTRAN dbname y userid se les eliminarán los blancos de cola antes del

proceso.

EXEC SQL CONNECT TO :dbname USER :userid USING :passwd

No obstante, puesto que los blancos pueden ser significativos en las

contraseñas, debe declarar las variables del lenguaje principal para

contraseñas como VARCHAR, y hacer que el campo de longitud establecido

refleje la longitud real de la contraseña:

EXEC SQL BEGIN DECLARE SECTION

character*8 dbname, userid

sql type is varchar(18) passwd


character*18 passwd_string

equivalence(passwd_data,passwd_string)

dbname = ’sample’


userid = ’userid’

passwd_length= 8

passwd_string = ’password’

EXEC SQL CONNECT TO :dbname USER :userid USING :passwd











grande (large object) en aplicaciones de SQL incorporado

FORTRAN


de objeto grande (LOB) en FORTRAN.

��

�

,

SQL TYPE IS

BLOB

(longitud

)

nombre-variable

CLOB

K

M

G

��


1. Los tipos GRAPHIC no se soportan en FORTRAN.

2. SQL TYPE IS, BLOB, CLOB, K, M, G se pueden especificar en mayúsculas, en

minúsculas o en una mezcla de ambas.

3. Para BLOB y CLOB 1 <= longitud-lob <= 2 147 483 647.

4. No se permite la inicialización de un LOB dentro de una declaración LOB.

5. El nombre de la variable del lenguaje principal es el prefijo de ’longitud? y

’datos’ en el código generado por el precompilador.

Ejemplo de BLOB:

La declaración:

sql type is blob(2m) my_blob


character my_blob(2097152+4)

integer*4 my_blob_length

character my_blob_data(2097152)

equivalence( my_blob(1),

+ my_blob_length )

equivalence( my_blob(5),

+ my_blob_data )

Ejemplo de CLOB:


La declaración:

sql type is clob(125m) my_clob


character my_clob(131072000+4)

integer*4 my_clob_length

character my_clob_data(131072000)

equivalence( my_clob(1),

+ my_clob_length )

equivalence( my_clob(5),

+ my_clob_data )












de localizador de objeto grande (LOB) en FORTRAN.

��

�

,

SQL TYPE IS

BLOB_LOCATOR

nombre-variable

CLOB_LOCATOR

��


LOB:


2. SQL TYPE IS, BLOB_LOCATOR, CLOB_LOCATOR se pueden especificar en


3. No se permite la inicialización de localizadores.

Ejemplo de localizador de CLOB (El localizador de BLOB es parecido):

La declaración:

SQL TYPE IS CLOB_LOCATOR my_locator


integer*4 my_locator








archivos aplicaciones de SQL incorporado FORTRAN


de referencia de archivos en FORTRAN.

��

�

,

SQL TYPE IS

BLOB_FILE

nombre-variable

CLOB_FILE

��

Consideraciones sobre variables del lenguaje principal de referencia de

archivos:


2. SQL TYPE IS, BLOB-FILE, CLOB-FILE se pueden especificar en mayúsculas, en

minúsculas o en una mezcla de ambas.

Ejemplo de una variable de referencia de archivos BLOB (La variable de

referencia de archivos CLOB es parecida):

SQL TYPE IS BLOB_FILE my_file


character my_file(267)

integer*4 my_file_name_length

integer*4 my_file_data_length

integer*4 my_file_file_options

character*255 my_file_name

equivalence( my_file(1),

+ my_file_name_length )


+ my_file_data_length )


+ my_file_file_options )


+ my_file_name )


v “Consideraciones sobre los juegos de caracteres gráficos (de varios bytes) en





Consideraciones sobre los juegos de caracteres gráficos (de

varios bytes) en aplicaciones de SQL incorporado FORTRAN

En FORTRAN no se da soporte a ningún tipo de datos de variables del lenguaje

principal de gráficos (de varios bytes). Sólo se da soporte a variables del lenguaje

principal de tipo carácter mixtas mediante el tipo de datos character. Sin embargo,

se puede crear una SQLDA de usuario que contenga datos gráficos.













UCS-2 para aplicaciones de SQL incorporado FORTRAN

Los datos gráficos enviados desde una aplicación que se ejecuta bajo un juego de

códigos eucJp o eucTW, o se conecta a una base de datos UCS-2, se identifican con

el identificador de la página de códigos UCS-2. La aplicación debe convertir una

serie de caracteres gráficos a UCS-2 antes de enviarla al servidor de bases de datos.

Del mismo modo, los datos gráficos recuperados de una base de datos UCS-2 por

una aplicación, o de cualquier base de datos por una aplicación que se ejecute bajo

una página de códigos EUC eucJP o eucTW, se codifican utilizando UCS-2. Esto

requiere que la aplicación realice internamente una conversión de UCS-2 a la

página de códigos de la aplicación, a menos que se vayan a presentar datos UCS-2

al usuario.

La aplicación es responsable de convertir a UCS-2 y desde UCS-2, puesto que esta

conversión se debe llevar a cabo antes de copiar los datos a la SQLDA o desde

esta. Los sistemas de bases de datos DB2 no suministran ninguna rutina de

conversión que resulte accesible para la aplicación. En cambio, se deben utilizar las

llamadas del sistema disponibles desde el sistema operativo. En el caso de una

base de datos UCS-2, también puede considerar la posibilidad de utilizar las

funciones escalares VARCHAR y VARGRAPHIC.





v “Función escalar VARCHAR” en Consulta de SQL, Volumen 1

v “Función escalar VARGRAPHIC” en Consulta de SQL, Volumen 1

Variables de indicador de nulo o de truncamiento en


Las variables de indicador se deben declarar con tipo de datos INTEGER*2.






v “Variables del lenguaje principal en FORTRAN” en la página 133






incorporado REXX

Variables del lenguaje principal en REXX

Las variables del lenguaje principal son variables del lenguaje REXX a las que se

hace referencia en las sentencias de SQL. Permiten a una aplicación intercambiar



otra variable de REXX. Cuando denomine, declare y utilice variables del lenguaje

principal, siga las normas descritas en los apartados siguientes.







v “Consideraciones sobre la programación de aplicaciones REXX de SQL



v “Variables de REXX predefinidas” en la página 143


SQL incorporado REXX

Cualquier variable de REXX correctamente denominada se puede utilizar como

variable del lenguaje principal. Un nombre de variable puede tener una longitud

máxima de 64 caracteres. No termine el nombre con un punto. Un nombre de

variable del lenguaje principal puede constar de números, caracteres alfabéticos y

los caracteres @, _, !, ., ? y $.







en la página 72

Referencias a variables del lenguaje principal en aplicaciones de

SQL incorporado REXX

El intérprete de REXX examina cada serie que no tiene comillas de un

procedimiento. Si la serie representa a una variable en la agrupación actual de

variables de REXX, éste sustituye la serie por el valor actual. A continuación se

muestra un ejemplo de cómo se puede hacer referencia a una variable del lenguaje

principal en REXX:

CALL SQLEXEC ’FETCH C1 INTO :cm’

SAY ’Commission = ’ cm


Para asegurarse de que una serie de caracteres no se convierta a un tipo de datos

numérico, encierre la serie entre comillas tal como en el ejemplo siguiente:

VAR = ’100’

REXX establece la variable VAR en la serie de caracteres de 3 bytes 100. Si se tienen

que incluir comillas como parte de la serie, siga este ejemplo:

VAR = "’100’"

Cuando se insertan datos numéricos en un campo de tipo CHARACTER, el

intérprete de REXX trata los datos numéricos como datos enteros, por lo que

deberá concatenar explícitamente las series numéricas y encerrarlas entre comillas.



en la página 72


Variables de REXX predefinidas

SQLEXEC, SQLDBS y SQLDB2 establecen variables de REXX predefinidas como

consecuencia de determinadas operaciones. Estas variables son:

RESULT

Cada operación establece este código de retorno. Los valores posibles son:

n Donde n es un valor positivo que indica el número de bytes de un

mensaje formateado. La API GET ERROR MESSAGE sola devuelve

este valor.

0 Se ha ejecutado la API. La SQLCA de la variable de REXX contiene

el estado de terminación de la API. Si SQLCA.SQLCODE es

distinto de cero, SQLMSG contiene el mensaje de texto asociado a

este valor.

–1 No se dispone de suficiente memoria para completar la API. No se

ha devuelto el mensaje solicitado.

–2 SQLCA.SQLCODE se establece en 0. No se ha devuelto ningún

mensaje.

–3 SQLCA.SQLCODE contenía un SQLCODE que no era válido. No

se ha devuelto ningún mensaje.

–6 No se ha podido crear la variable SQLCA de REXX. Esto indica

que no había suficiente memoria disponible o que la agrupación de

variables de REXX no estaba disponible por algún motivo.

–7 No se ha podido crear la variable SQLMSG de REXX. Esto indica

que no había suficiente memoria disponible o que la agrupación de

variables de REXX no estaba disponible por algún motivo.

–8 No se ha podido captar la variable SQLCA.SQLCODE de REXX de

la agrupación de variables de REXX.

–9 La variable SQLCA.SQLCODE de REXX se ha truncado durante la

captación. La longitud máxima para esta variable es de 5 bytes.

–10 La variable SQLCA.SQLCODE de REXX no se ha podido convertir

de ASCII a un entero largo válido.


–11 No se ha podido captar la variable SQLCA.SQLERRML de REXX

de la agrupación de variables de REXX.

–12 La variable SQLCA.SQLERRML de REXX se ha truncado durante

la captación. La longitud máxima para esta variable es de 2 bytes.

–13 La variable SQLCA.SQLERRML de REXX no se ha podido

convertir de ASCII a un entero corto válido.

–14 No se ha podido captar la variable SQLCA.SQLERRMC de REXX

de la agrupación de variables de REXX.

–15 La variable SQLCA.SQLERRMC de REXX se ha truncado durante

la captación. La longitud máxima para esta variable es de 70 bytes.

–16 No se ha podido establecer la variable de REXX especificada para

el texto del error.

–17 No se ha podido captar la variable SQLCA.SQLSTATE de REXX de

la agrupación de variables de REXX.

–18 La variable SQLCA.SQLSTATE de REXX se ha truncado durante la

captación. La longitud máxima para esta variable es de 2 bytes.

Nota: Los valores –8 a –18 sólo los devuelve la API GET ERROR

MESSAGE.

SQLMSG

Si SQLCA.SQLCODE es distinto de cero, esta variable contiene el mensaje

de texto asociado al código de error.

SQLISL

Nivel de aislamiento. Los valores posibles son:

RR Lectura repetible.

RS Estabilidad de lectura.

CS Estabilidad del cursor. Éste es el valor por omisión.

UR Lectura no confirmada.

NC Sin confirmación. (NC sólo recibe soporte de algunos servidores de

sistema principal, AS/400 o iSeries.)

SQLCA

La estructura SQLCA actualizada después de que se procesen las

sentencias de SQL y se llame a las API de DB2.

SQLRODA

La estructura SQLDA de entrada/salida para procedimientos almacenados

invocados mediante la sentencia CALL. También es la estructura SQLDA

de salida para procedimientos almacenados invocados mediante la API

Database Application Remote Interface (DARI).

SQLRIDA

La estructura SQLDA de entrada para procedimientos almacenados

invocados mediante la API Database Application Remote Interface (DARI).

SQLRDAT

Una estructura SQLCHAR para procedimientos de servidor invocados

mediante la API Database Application Remote Interface (DARI).









v “Estructura de datos SQLCA” en Consulta de las API administrativas

v “Estructura de datos sqlchar” en Consulta de las API administrativas

v “Estructura de datos SQLDA” en Consulta de las API administrativas

Consideraciones sobre la programación de aplicaciones REXX

de SQL incorporado

REXX es un lenguaje interpretado. Por lo tanto, no se utiliza ningún

precompilador, compilador ni enlazador. En su lugar, se utilizan tres API de DB2

para crear aplicaciones DB2 en REXX. Utilice dichas API para acceder a distintos

elementos de DB2.

SQLEXEC

Da soporte al lenguaje SQL.

SQLDBS

Da soporte a las versiones de línea de mandatos de las API de DB2.

SQLDB2

Da soporte a una interfaz específica de REXX con el procesador de línea de

mandatos. Consulte la descripción de la sintaxis de la API para REXX para

ver detalles y restricciones sobre cómo se puede utilizar esta interfaz.

Antes de utilizar cualquiera de las API de DB2 o emitir sentencias de SQL en una

aplicación, debe registrar las rutinas SQLDBS, SQLDB2 y SQLEXEC. Así se notifica

al intérprete de REXX sobre los puntos de entrada de REXX/SQL. El método que

utilice para realizar el registro variará ligeramente entre las plataformas basadas en

Windows y AIX.

Procedimiento:

Utilice los ejemplos siguientes para ver la sintaxis correcta para registrar cada

rutina:

Registro de ejemplo en sistemas operativos basados en Windows

/* ------------ Registrar SQLDBS con REXX -------------------------*/

If Rxfuncquery('SQLDBS') <> 0 then

rcy = Rxfuncadd('SQLDBS','DB2AR','SQLDBS')

If rcy \= 0 then

do

say ’SQLDBS was not successfully added to the REXX environment’

signal rxx_exit

end

/* ------------ Registrar SQLDB2 con REXX -------------------------*/

If Rxfuncquery('SQLDB2') <> 0 then

rcy = Rxfuncadd('SQLDB2','DB2AR','SQLDB2')

If rcy \= 0 then

do

say ’SQLDB2 was not successfully added to the REXX environment’

signal rxx_exit

end

/* ----------------- Registrar SQLEXEC con REXX --------------------*/

If Rxfuncquery('SQLEXEC') <> 0 then

rcy = Rxfuncadd('SQLEXEC','DB2AR','SQLEXEC')


If rcy \= 0 then

do

say ’SQLEXEC was not successfully added to the REXX environment’

signal rxx_exit

end

Registro de ejemplo en AIX

/* ------------ Registrar SQLDBS, SQLDB2 y SQLEXEC con REXX --------*/

rcy = SysAddFuncPkg("db2rexx")

If rcy \= 0 then

do

say ’db2rexx was not successfully added to the REXX environment’

signal rxx_exit

end

En plataformas basadas en Windows, sólo es necesario ejecutar una vez el mandato

RxFuncAdd para todas las sesiones.

En AIX, se debe ejecutar SysAddFuncPkg en cada aplicación REXX/SQL.

En la documentación de REXX para plataformas basadas en Windows y AIX,

respectivamente, encontrará detalles sobre las API Rxfuncadd y SysAddFuncPkg.

Es posible que los símbolos que se encuentren dentro de sentencias o mandatos

que se pasen a las rutinas SQLEXEC, SQLDBS y SQLDB2 puedan corresponder a

variables de REXX. En este caso, el intérprete de REXX sustituye el valor de la

variable antes de llamar a SQLEXEC, SQLDBS o SQLDB2.

Para evitar esta situación, encierre las series de sentencias entre comillas (’ ’ o ″ ″).

Si no utiliza comillas, el intérprete de REXX resolverá los nombres de variable

conflictivos, en lugar de que se pasen a las rutinas SQLEXEC, SQLDBS o SQLDB2.




grande (large object) en aplicaciones de SQL incorporado REXX

Cuando se capte una columna LOB en una variable del lenguaje principal REXX,

esta se almacenará como una serie simple (es decir, descontada). Esto se maneja del

mismo modo que todos los tipos de SQL basados en caracteres (tales como CHAR,

VARCHAR, GRAPHIC, LONG, etc.). En la entrada, si el tamaño del contenido de

la variable del lenguaje principal es superior a 32 K, o si cumple con otros criterios

establecidos más adelante, se le asignará el tipo de LOB apropiado.

En SQL de REXX, los tipos de SQL se determinan a partir del contenido de la serie

de la variable del lenguaje principal, del modo siguiente:

Contenido de la serie de variable del lenguaje principal Tipo de LOB resultante

:hv1=’serie normal entre comillas de más de 32 K ...’ CLOB

:hv2=″’serie con comillas de delimitación incorporadas ″,

″de más de 32 K...’″

CLOB

:hv3=″G’serie DBCS con comillas de delimitación incorporadas, ″,

″que empieza por G, de más de 32 K...’″

DBCLOB

:hv4=″BIN’serie con comillas de delimitación incorporadas, ″,

″que empieza por BIN, de cualquier longitud...’″

BLOB



v “Borrado de variables del lenguaje principal de LOB en aplicaciones de SQL




grande (large object locator) en aplicaciones de SQL incorporado REXX” en la

página 147



aplicaciones de SQL incorporado REXX


de localizador de LOB en REXX:

��

�

,

DECLARE

:

nombre-variable

LANGUAGE TYPE

BLOB

LOCATOR

CLOB

DBCLOB

��

Debe declarar las variables del lenguaje principal de localizador de LOB en la

aplicación. Cuando REXX/SQL encuentra estas declaraciones, trata las variables

del lenguaje principal declaradas como localizadores durante el resto del

programa. Los valores de localizadores se almacenan en variables de REXX, en un

formato interno.

Ejemplo:

CALL SQLEXEC ’DECLARE :hv1, :hv2 LANGUAGE TYPE CLOB LOCATOR’

Los datos representados por localizadores de LOB devueltos por el mecanismo se

pueden liberar en REXX/SQL mediante la sentencia FREE LOCATOR, que tiene el

formato siguiente:

Sintaxis de la sentencia FREE LOCATOR

��

�

,

FREE

LOCATOR

:

nombre-variable

��

Ejemplo:

CALL SQLEXEC ’FREE LOCATOR :hv1, :hv2’





v “Sentencia FREE LOCATOR” en Consulta de SQL, Volumen 2


en la página 72




archivos en aplicaciones de SQL incorporado REXX

Debe declarar las variables del lenguaje principal de referencia de archivos LOB en

la aplicación. Cuando REXX/SQL encuentra estas declaraciones, trata las variables

del lenguaje principal declaradas como referencias de archivos LOB durante el

resto del programa.


de referencia de archivos LOB en REXX:

��

�

,

DECLARE

:

nombre-variable

LANGUAGE TYPE

BLOB

FILE

CLOB

DBCLOB

��

Ejemplo:

CALL SQLEXEC ’DECLARE :hv3, :hv4 LANGUAGE TYPE CLOB FILE’

Las variables de referencia de archivos en REXX contienen tres campos. Para el

ejemplo anterior, éstos son:

hv3.FILE_OPTIONS.

Establecido por la aplicación para indicar cómo se utilizará el archivo.

hv3.DATA_LENGTH.

Establecido por DB2 para indicar el tamaño del archivo.

hv3.NAME.

Establecido por la aplicación con el nombre del archivo LOB.

Para FILE_OPTIONS, la aplicación establece las palabras clave siguientes:

Palabra clave (valor entero)

Significado

READ (2) El archivo se va a utilizar como entrada. Se trata de un archivo

normal que se puede abrir, leer y cerrar. La longitud de los datos

del archivo (en bytes) se calcula (lo hace el código solicitante de la

aplicación) al abrir el archivo.

CREATE (8) En la salida, crear un nuevo archivo. Si el archivo ya existe, es un

error. La longitud (en bytes) del archivo se devuelve en el campo

DATA_LENGTH de la estructura de la variable de referencia de

archivos.

OVERWRITE (16)

En la salida, se sobregraba el archivo, si ya existe; de lo contrario,

se crea un nuevo archivo. La longitud (en bytes) del archivo se

devuelve en el campo DATA_LENGTH de la estructura de la variable

de referencia de archivos.

APPEND (32) La salida se añade al archivo, si existe; de lo contrario, se crea un

nuevo archivo. La longitud (en bytes) de los datos que se han

añadido al archivo (y no la longitud total del archivo) se devuelve

en el campo DATA_LENGTH de la estructura de la variable de

referencia de archivos.


Nota: Una variable del lenguaje principal de referencia de archivos es una variable

compuesta en REXX, por lo que debe establecer valores para los campos

NAME, NAME_LENGTH y FILE_OPTIONS además de declararlas.







en la página 72

Borrado de variables del lenguaje principal de LOB en


En plataformas basadas en Windows, puede ser necesario borrar explícitamente las

declaraciones de variables del lenguaje principal de referencia de archivos y de

localizador de LOB de SQL de REXX, puesto que permanecen en vigor una vez

que finaliza el programa de aplicación. Esto es debido a que el proceso de la

aplicación no sale hasta que se cierra la sesión en la que se ejecuta. Si no se borran

las declaraciones de LOB del SQL para REXX, pueden interferir con otras

aplicaciones que se ejecuten en la misma sesión después de que se haya ejecutado

una aplicación de LOB.

La sintaxis para borrar la declaración es:

CALL SQLEXEC "CLEAR SQL VARIABLE DECLARATIONS"

Debe codificar esta sentencia al final de las aplicaciones de LOB. Observe que la

puede codificar en cualquier lugar, como medida de precaución, para borrar las

declaraciones que puedan haber quedado de aplicaciones anteriores (por ejemplo,

al principio de una aplicación SQL en REXX).




v “Creación y ejecución de aplicaciones de SQL incorporado escritas en REXX” en

la página 265

Variables de indicador de nulo o de truncamiento en

aplicaciones de SQL incorporado REXX

El tipo de datos de una variable de indicador en REXX es un número sin coma

decimal. A continuación se muestra un ejemplo de variable de indicador en REXX

que utiliza la palabra clave INDICATOR.

CALL SQLEXEC ’FETCH C1 INTO :cm INDICATOR :cmind’

IF ( cmind < 0 )

SAY ’Commission is NULL’

En el ejemplo anterior, se examina que cmind tenga un valor negativo. Si no es

negativo, la aplicación puede utilizar el valor devuelto de cm. Si es negativo, el

valor captado es NULL y no se debe utilizar cm. En este caso, el gestor de bases de

datos no cambia el valor de la variable del lenguaje principal.



v “Variables del lenguaje principal en REXX” en la página 142



en la página 72

Ejecución de sentencias de SQL en aplicaciones de SQL incorporado

Ejecución de sentencias de SQL en aplicaciones de SQL

incorporado

La ejecución de sentencias de SQL en aplicaciones de SQL incorporado es distinta

para sentencias ejecutadas estáticamente y dinámicamente, aunque ambas utilizan

el mandato EXEC SQL. Las sentencias estáticas están codificadas de manera fija en el

código fuente de una aplicación de SQL incorporado. Las sentencias dinámicas se

diferencian de las estáticas en que se compilan en tiempo de ejecución y pueden

prepararse con parámetros de entrada. La información leída puede almacenarse en

un medio denominado cursor, que entonces permite a los usuarios desplazarse

libremente por los datos y realizar las actualizaciones correspondientes. La

información de errores de SQLCODE, SQLSTATE y SQLWARN es una herramienta

útil para la ayuda para resolver problemas de una aplicación.


v “Llamada a procedimientos almacenados en aplicaciones de SQL incorporado”

en la página 171



página 191

v “Ejecución de sentencias de SQL estático en aplicaciones de SQL incorporado”

en la página 151

v “Lectura de los conjuntos de resultados y desplazamiento por los mismos en





Comentarios en aplicaciones de SQL incorporado

Los comentarios en cualquier aplicación son importantes para que el código de la

aplicación se pueda entender. Esta sección trata sobre cómo añadir comentarios en


Comentarios en aplicaciones de SQL incorporado C y C++:

Cuando se trabaja con aplicaciones C y C++, se pueden insertar comentarios de

SQL dentro del bloque EXEC SQL. Por ejemplo:

/* Aquí sólo se permiten comentarios de C o C++ */

EXEC SQL

-- Aquí se permiten comentarios de SQL

/* o comentarios de C */


// o comentarios de C++

DECLARE C1 CURSOR FOR sname;

/* Aquí sólo se permiten comentarios de C o C++ */

Comentarios en aplicaciones de SQL incorporado COBOL:

Cuando se trabaja con aplicaciones COBOL, se pueden insertar comentarios de


* Consulte la documentación de COBOL para conocer

* las reglas sobre comentarios

* Aquí sólo se permiten comentarios de COBOL

EXEC SQL

-- Aquí se permiten comentarios de SQL

* o comentarios de COBOL de línea completa

DECLARE C1 CURSOR FOR sname END-EXEC.

* Aquí sólo se permiten comentarios de COBOL

Comentarios en aplicaciones de SQL incorporado FORTRAN:

Cuando se trabaja con aplicaciones FORTRAN, se pueden insertar comentarios de


C Aquí sólo se permiten comentarios de FORTRAN

EXEC SQL

+ -- comentarios de SQL y

C comentarios de FORTRAN de línea completa

+ DECLARE C1 CURSOR FOR sname

I=7 ! Fin de línea Se permiten comentarios de FORTRAN

C Aquí sólo se permiten comentarios de FORTRAN

Comentarios en aplicaciones de SQL incorporado REXX:

Los comentarios de SQL no están soportados en aplicaciones REXX.



Ejecución de sentencias de SQL estático en aplicaciones de

SQL incorporado

Las sentencias de SQL se pueden ejecutar estáticamente en un lenguaje principal

utilizando el siguiente enfoque:

v C o C++ (tut_mod.sqc/tut_mod.sqC)

Los tres ejemplos siguientes proceden del ejemplo tut_mod. Consulte este

ejemplo para ver un programa completo que muestra cómo modificar datos de

tablas en C o C++.

El siguiente ejemplo muestra cómo insertar datos de tablas:

EXEC SQL INSERT INTO staff(id, name, dept, job, salary)

VALUES(380, ’Pearce’, 38, ’Clerk’, 13217.50),

(390, ’Hachey’, 38, ’Mgr’, 21270.00),

(400, ’Wagland’, 38, ’Clerk’, 14575.00);

El siguiente ejemplo muestra cómo actualizar datos de tablas:

EXEC SQL UPDATE staff

SET salary = salary + 10000

WHERE id >= 310 AND dept = 84;

El siguiente ejemplo muestra cómo suprimir datos de una tabla:


EXEC SQL DELETE

FROM staff

WHERE id >= 310 AND salary > 20000;

v COBOL (updat.sqb)

Los tres ejemplos siguientes proceden del ejemplo updat. Consulte este ejemplo

para ver un programa completo que muestra cómo modificar datos de tablas en

COBOL.

El siguiente ejemplo muestra cómo insertar datos de tablas:

EXEC SQL INSERT INTO staff

VALUES (999, ’Testing’, 99, :job-update, 0, 0, 0)

END-EXEC.

El siguiente ejemplo muestra cómo actualizar datos de una tabla; job-update es

una referencia a una variable del lenguaje principal declarada en la sección de

declaración del código fuente:

EXEC SQL UPDATE staff

SET job=:job-update

WHERE job=’Mgr’

END-EXEC.

El siguiente ejemplo muestra cómo suprimir datos de una tabla:

EXEC SQL DELETE

FROM staff

WHERE job=:job-update

END-EXEC.


v “Determinación del momento en que deben ejecutarse sentencias de SQL estática

o dinámicamente en aplicaciones de SQL incorporado” en la página 22




Recuperación de información de variables del lenguaje

principal procedente de la estructura SQLDA en aplicaciones

de SQL incorporado

Recuperación de información de variables del lenguaje principal

procedente de la estructura SQLDA en aplicaciones de SQL

incorporado

Con SQL estático, las variables del lenguaje principal utilizadas en sentencias de

SQL incorporado se conocen en el momento de compilar la aplicación. Con SQL

dinámico, las sentencias de SQL incorporado y por lo tanto las variables del

lenguaje principal no se conocen hasta el momento de ejecutar la aplicación. Por lo

tanto, para aplicaciones de SQL dinámico, tiene que trabajar con la lista de las

variables del lenguaje principal que se utilizan en la aplicación. Puede utilizar la

sentencia DESCRIBE para obtener información sobre variables del lenguaje

principal para cualquier sentencia SELECT que se haya preparado (mediante

PREPARE) y almacenar dicha información en el área del descriptor de SQL

(SQLDA).

Cuando la sentencia DESCRIBE se ejecuta en la aplicación, el gestor de bases de

datos define las variables del lenguaje principal en una SQLDA. Cuando las


variables del lenguaje principal se han definido en la SQLDA, puede utilizar la

sentencia FETCH para asignar valores a las variables del lenguaje principal,

mediante un cursor.


v “Ejemplo de un cursor en una aplicación de SQL ejecutada dinámicamente” en

la página 187




v “Sentencia DESCRIBE” en Consulta de SQL, Volumen 2

v “Sentencia FETCH” en Consulta de SQL, Volumen 2



Declaración de la estructura SQLDA en un programa de SQL

ejecutado dinámicamente

La SQLDA contiene un número de ocurrencias de variables de entradas SQLVAR,

cada una de las cuales contiene un grupo de campos que describen una columna

de una fila de datos, tal como se muestra en la siguiente figura. Hay dos tipos de

entradas SQLVAR: entradas SQLVAR base y entradas SQLVAR secundarias.

Procedimiento:

Puesto que el número de entradas SQLVAR necesario depende del número de

columnas de la tabla de resultados, una aplicación debe ser capaz de asignar un

número adecuado de elementos SQLVAR cuando se necesiten. Utilice uno de los

siguientes métodos:

v Proporcione la SQLDA de mayor tamaño (es decir, la que tenga el mayor

número de entradas SQLVAR) que se necesite. El número máximo de columnas

que se pueden devolver en una tabla de resultados es 255. Si cualquiera de las

columnas devueltas es un tipo LOB o un tipo diferenciado, el valor de SQLN se

Figura 3. El Área de descriptores de SQL (SQLDA)


dobla y el número de entradas SQLVAR necesarias para albergar la información

se dobla a 510. Sin embargo, puesto que la mayoría de sentencias SELECT no

recuperan ni 255 columnas, la mayoría del espacio asignado no se utiliza.

v Proporcione una SQLDA de menor tamaño con menos entradas SQLVAR. En

este caso, si hay más columnas en el resultado que entradas SQLVAR permitidas

en la SQLDA, no se devuelve ninguna descripción. En su lugar, el gestor de

bases de datos devuelve el número de elementos de lista de selección detectado

en la sentencia SELECT. La aplicación asigna una SQLDA con el número de

entradas SQLVAR necesario y utiliza la sentencia DESCRIBE para adquirir las

descripciones de columnas.

v Cuando el número de columnas devuelto es del tipo LOB o definido por el

usuario, proporcione una SQLDA con el número exacto de entradas SQLVAR.

Para los tres métodos, la duda es cuántas entradas SQLVAR iniciales se deben

asignar. Cada elemento SQLVAR utiliza un máximo de 44 bytes de almacenamiento

(sin contar el almacenamiento asignado para los campos SQLDATA y SQLIND). Si

hay memoria suficiente, el primer método de proporcionar una SQLDA de tamaño

máximo resulta más fácil de implementar.

El segundo método de asignar una SQLDA de menor tamaño sólo se aplica a

lenguajes de programación, como C y C++, que dan soporte a la asignación

dinámica de memoria. Para lenguajes como COBOL y FORTRAN, que no dan

soporte a la asignación dinámica de memoria, utilice el primer método.


v “Identificar valores XML en una SQLDA” en la página 80


v “Asignación de una estructura SQLDA para un programa de SQL ejecutado


v “Asignación de una estructura SQLDA con suficientes entradas SQLVAR para

sentencias de SQL ejecutadas dinámicamente” en la página 156



v “Preparación de una sentencia de SQL ejecutada dinámicamente utilizando la

estructura SQLDA mínima” en la página 154



Preparación de una sentencia de SQL ejecutada dinámicamente

utilizando la estructura SQLDA mínima

Utilice la información de este tema como ejemplo sobre cómo asignar la estructura

SQLDA mínima para una sentencia.

Restricciones:

Sólo puede asignar una estructura SQLDA de menor tamaño con lenguajes de

programación, como C y C++, que den soporte a la asignación dinámica de

memoria.

Procedimiento:


Supongamos que una aplicación declara una estructura SQLDA denominada

minsqlda que no contiene ninguna entrada SQLVAR. El campo SQLN de la SQLDA

describe el número de entradas SQLVAR que se asignan. En este caso, SQLN se

debe establecer en 0. A continuación, para preparar una sentencia desde la serie de

caracteres dstring y para entrar su descripción en minsqlda, emita la siguiente

sentencia de SQL (suponiendo que se utiliza sintaxis de C y que minsqlda se

declara como un puntero a una estructura SQLDA):

EXEC SQL

PREPARE STMT INTO :*minsqlda FROM :dstring;

Supongamos que la sentencia contenida es dstring es una sentencia SELECT que

devuelve 20 columnas en cada fila. Después de la sentencia PREPARE (o de una

sentencia DESCRIBE), el campo SQLD de la SQLDA contiene el número de

columnas de la tabla de resultados correspondiente a la sentencia SELECT

preparada.

Las entradas SQLVAR de la SQLDA se establecen en los casos siguientes:

v SQLN >= SQLD y ninguna columna tiene el tipo LOB ni un tipo diferenciado.

Las primeras entradas SQLVAR de SQLD se establecen y SQLDOUBLED se

establece en blanco.

v SQLN >= 2*SQLD y al menos una columna es de tipo LOB o tiene un tipo

diferenciado.

2* entradas SQLVAR de SQLD se establecen y SQLDOUBLED se establece en 2.

v SQLD <= SQLN < 2*SQLD y al menos una columna tiene un tipo diferenciado,

pero no hay ninguna columna LOB.

Las primeras entradas SQLVAR de SQLD se establecen y SQLDOUBLED se

establece en blanco. Si la opción de vinculación SQLWARN tiene el valor YES, se

emite un aviso SQLCODE +237 (SQLSTATE 01594).

Las entradas SQLVAR de la SQLDA no se establecen (es necesaria la asignación de

espacio adicional y otra sentencia DESCRIBE) en los casos siguientes:

v SQLN < SQLD y ninguna columna tiene el tipo LOB ni un tipo diferenciado.

No se establece ninguna entrada SQLVAR y SQLDOUBLED se establece en

blanco. Si la opción de vinculación SQLWARN tiene el valor YES, se emite un

aviso SQLCODE +236 (SQLSTATE 01005).

Asigne entradas SQLVAR de SQLD para lograr una operación DESCRIBE

satisfactoria.

v SQLN < SQLD y al menos una columna tiene un tipo diferenciado, pero no hay

ninguna columna LOB.


blanco. Si la opción de vinculación SQLWARN tiene el valor YES, se emite un

aviso SQLCODE +239 (SQLSTATE 01005).

Asigne 2*SQLD entradas SQLVAR para lograr una operación DESCRIBE

satisfactoria, incluidos los nombres de los tipos diferenciados.

v SQLN < 2*SQLD y al menos una columna es de tipo LOB.


blanco. Se emite un aviso SQLCODE +238 (SQLSTATE 01005)

(independientemente del valor de la opción de vinculación SQLWARN).

Asigne 2*SQLD entradas SQLVAR para lograr una operación DESCRIBE

satisfactoria.


La opción SQLWARN del mandato BIND sirve para controlar si DESCRIBE (o

PREPARE...INTO) devolverá los siguientes avisos:

v SQLCODE +236 (SQLSTATE 01005)

v SQLCODE +237 (SQLSTATE 01594)

v SQLCODE +239 (SQLSTATE 01005).

Se recomienda que el código de la aplicación siempre tenga en cuenta que se

pueden devolver estos valores SQLCODE. Siempre se devuelve el aviso SQLCODE

+238 (SQLSTATE 01005) cuando hay columnas LOB en la lista de selección y hay

un número insuficiente de entradas SQLVAR en la SQLDA. Esta es la única manera

que tiene la aplicación para saber que el número de entradas SQLVAR se debe

doblar debido a una columna LOB en el conjunto de resultados.








Asignación de una estructura SQLDA con suficientes entradas

SQLVAR para sentencias de SQL ejecutadas dinámicamente

Después de determinar el número de columnas de la tabla de resultados, asigne

almacenamiento para un segundo SQLDA de tamaño completo. El primer SQLDA

se utiliza para parámetros de entrada y el segundo SQLDA de tamaño completo se

utiliza para parámetros de salida.

Procedimiento:

Supongamos que la tabla de resultados tiene 20 columnas (ninguna de las cuales es

de tipo LOB). En esta situación, debe asignar una segunda estructura SQLDA,

fulsqlda, con un mínimo de 20 elementos SQLVAR (o 40 elementos si la tabla de

resultados contiene algún LOB o tipo diferenciado). Para el resto de este ejemplo,

supongamos que no hay ningún LOB ni tipo diferenciado en la tabla de resultados.

Cuando calcule los requisitos de almacenamiento para estructuras de SQLDA,

incluya lo siguiente:

v Una cabecera de longitud fija, de 16 bytes de longitud, que contiene campos

como SQLN y SQLD

v Una matriz de longitud variable de entradas SQLVAR, de la cual cada elemento

tiene 44 bytes de longitud en plataformas de 32 bits y 56 bytes de longitud en

plataformas de 64 bits.

El número de entradas SQLVAR necesarias para fulsqlda se especifica en el campo

SQLD de minsqlda. Supongamos que este valor es 20. Por lo tanto, la asignación de

almacenamiento necesaria para fulsqlda es:

16 + (20 * sizeof(struct sqlvar))

Este valor representa el tamaño de la cabecera más 20 multiplicado por el tamaño

de cada entrada SQLVAR, lo que da un total de 896 bytes.


Puede utilizar la macro SQLDASIZE para no tener que realizar sus propios

cálculos y para evitar dependencias específicas de cada versión.








Descripción de una sentencia SELECT en un programa de SQL


Después de asignar espacio suficiente para el segundo SQLDA (en este ejemplo,

denominado fulsqlda), debe codificar la aplicación para que describa la sentencia

SELECT.

Procedimiento:

Codifique la aplicación para que lleve a cabo los pasos siguientes:

1. Almacenar el valor 20 en el campo SQLN de fulsqlda (en este ejemplo se

supone que la tabla de resultados contiene 20 columnas y que ninguna de ellas

es una columna LOB).

2. Obtener información sobre la sentencia SELECT mediante la segunda estructura

SQLDA, fulsqlda. Hay dos métodos disponibles:

v Utilizar otra sentencia PREPARE, especificando fulsqlda en lugar de

minsqlda.

v Utilizar la sentencia DESCRIBE especificando fulsqlda.

Es preferible utilizar la sentencia DESCRIBE porque se evita el coste de preparar la

sentencia por segunda vez. La sentencia DESCRIBE simplemente reutiliza la

información obtenida previamente durante la operación de preparación para llenar

la nueva estructura SQLDA. Se puede emitir la siguiente sentencia:

EXEC SQL DESCRIBE STMT INTO :fulsqlda

Una vez ejecutada esta sentencia, cada elemento SQLVAR contiene una descripción

de una columna de la tabla de resultados.





v “Adquisición de almacenamiento para albergar una fila” en la página 158





v “Sentencia SELECT” en Consulta de SQL, Volumen 2



Adquisición de almacenamiento para albergar una fila

Para que una aplicación pueda captar una fila de la tabla de resultados utilizando

una estructura SQLDA, la aplicación debe antes asignar almacenamiento para la

fila.

Procedimiento:

Codifique la aplicación de modo que haga lo siguiente:

1. Analice cada descripción de SQLVAR para determinar cuánto espacio se

necesita para el valor de dicha columna.

Tenga en cuenta que, para valores LOB, cuando se describe la sentencia

SELECT, los datos que se proporcionan en la SQLVAR son SQL_TYP_xLOB.

Este tipo de datos corresponde a una variable del lenguaje principal LOB plana,

es decir, el LOB completo se almacena en memoria de una sola vez. Esto

funciona para LOB pequeños (de un máximo de unos pocos MB), pero no

puede utilizar este tipo de datos para LOB grandes (por ejemplo, de 1 GB)

porque la pila no puede asignar suficiente memoria. Será necesario que la

aplicación cambie su definición de columna en la SQLVAR para que sea

SQL_TYP_xLOB_LOCATOR o SQL_TYPE_xLOB_FILE. (Tenga en que cuenta

que, si se cambia el campo SQLTYPE de la SQLVAR, también se tiene que

cambiar el campo SQLLEN.) Después de cambiar la definición de columna en

la SQLVAR, la aplicación puede asignar la cantidad correcta de almacenamiento

correspondiente al nuevo tipo.

2. Asigne almacenamiento para el valor de dicha columna.

3. Almacene la dirección del almacenamiento asignado en el campo SQLDATA de

la estructura SQLDA.

Estos pasos se deben llevar a cabo analizando la descripción de cada columna y

sustituyendo el contenido de cada campo SQLDATA por la dirección de un área de

almacenamiento lo suficientemente grande como para albergar cualquier valor

procedente de dicha columna. El atributo de longitud se determina a partir del

campo SQLLEN de cada entrada SQLVAR correspondiente a elementos de datos

que no son de tipo LOB. Para elementos con un tipo BLOB, CLOB o DBCLOB, el

atributo de longitud se determina a partir del campo SQLLONGLEN de la entrada

SQLVAR secundaria.

Además, si la columna especificada permite nulos, la aplicación debe sustituir el

contenido del campo SQLIND por la dirección de una variable de indicador

correspondiente a la columna.




v “Uso de objetos grandes” en Desarrollo de SQL y rutinas externas






v “Proceso del cursor en un programa SQL ejecutado dinámicamente” en la página

159




Proceso del cursor en un programa SQL ejecutado

dinámicamente

Después de asignar correctamente la estructura SQLDA, el cursor asociado con la

sentencia SELECT se puede abrir y se pueden captar filas.

Procedimiento:

Para procesar el cursor asociado con una sentencia SELECT, primero abra el cursor

y luego capte filas especificando la cláusula USING DESCRIPTOR de la sentencia

FETCH. Por ejemplo, una aplicación C podría tener lo siguiente:

EXEC SQL OPEN pcurs

EMB_SQL_CHECK( "OPEN" ) ;

EXEC SQL FETCH pcurs USING DESCRIPTOR :*sqldaPointer

EMB_SQL_CHECK( "FETCH" ) ;

Para procesar una operación FETCH satisfactoriamente, podría escribir la

aplicación de modo que obtuviera los datos de la SQLDA y mostrara las cabeceras

de columna. Por ejemplo:

display_col_titles( sqldaPointer ) ;

Una vez visualizados los datos, debería cerrar el cursor y liberar la memoria

asignada de forma dinámica. Por ejemplo:

EXEC SQL CLOSE pcurs ;

EMB_SQL_CHECK( "CLOSE CURSOR" ) ;


v “Tipos de cursores y consideraciones sobre unidad de trabajo en aplicaciones de



la página 187






v “Selección de varias filas utilizando un cursor en aplicaciones de SQL


v “Colocación de un cursor en una fila con un determinado valor de columna” en

la página 183

v “Declaración y utilización de cursores en una aplicación de SQL ejecutada


Asignación de una estructura SQLDA para un programa de SQL


Asigne una estructura SQLDA correspondiente a la aplicación de modo que pueda

utilizarla para pasar datos a la aplicación y para recibir datos de esta.

Procedimiento:


Para crear una estructura SQLDA con C, incorpore la sentencia INCLUDE SQLDA

en el lenguaje principal o incluya el archivo include de SQLDA para obtener la

definición de estructura. Luego, debido a que el tamaño de una SQLDA no es fijo,

la aplicación debe declarar un puntero a una estructura SQLDA y asignar

almacenamiento para la misma. El tamaño real de la estructura SQLDA depende

del número de elementos de datos diferenciados que se pasan mediante la SQLDA.

En el lenguaje de programación C y C++, se proporciona una macro que facilita la

asignación de SQLDA. Esta macro tiene el siguiente formato:

#define SQLDASIZE(n) (offsetof(struct sqlda, sqlvar) \

+ (n) × sizeof(struct sqlvar))

El efecto de esta macro es calcular el almacenamiento necesario para una SQLDA

con n elementos SQLVAR.

Para crear una estructura SQLDA con COBOL, puede incorporar una sentencia

INCLUDE SQLDA o utilizar la sentencia COPY. Utilice la sentencia COPY cuando

desee controlar el número máximo de entradas SQLVAR y por tanto la cantidad de

espacio de almacenamiento ocupado por la SQLDA. Por ejemplo, para cambiar el

número por omisión de entradas SQLVAR de 1489 a 1, utilice la siguiente sentencia

COPY:

COPY "sqlda.cbl"

replacing --1489--

by --1--.

El lenguaje FORTRAN no da soporte directamente a las estructuras de datos

autodefinidas ni a la asignación dinámica. No se proporciona ningún archivo

include de SQLDA para FORTRAN porque no es posible dar soporte a la SQLDA

como una estructura de datos en FORTRAN. El precompilador pasará por alto la

sentencia INCLUDE SQLDA en un programa FORTRAN.

Sin embargo, puede crear algo parecido a una estructura SQLDA estática en un

programa FORTRAN y utilizar dicha estructura siempre que se pueda utilizar una

SQLDA. El archivo sqldact.f contiene constantes que ayudan a declarar una

estructura SQLDA en FORTRAN.

Ejecute llamadas a SQLGADDR para asignar valores de puntero a elementos de

SQLDA que los necesiten.

La tabla siguiente muestra la declaración y uso de una estructura SQLDA con un

elemento SQLVAR.


C y C++

#include

struct sqlda *outda = (struct sqlda *)malloc(SQLDASIZE(1));

/* DECLARAR VARIABLES LOCALES PARA ALBERGAR DATOS REALES */

double sal = 0;

short salind = 0;

/* INICIALIZAR UN ELEMENTO DE SQLDA */

memcpy( outda->sqldaid,"SQLDA ",sizeof(outda->sqldaid));

outda->sqln = outda->sqld = 1;

outda->sqlvar[0].sqltype = SQL_TYP_NFLOAT;

outda->sqlvar[0].sqllen = sizeof( double );.

outda->sqlvar[0].sqldata = (unsigned char *)&sal;

outda->sqlvar[0].sqlind = (short *)&salind;



COBOL

WORKING-STORAGE SECTION.

77 SALARY PIC S99999V99 COMP-3.

77 SAL-IND PIC S9(4) COMP-5.

EXEC SQL INCLUDE SQLDA END-EXEC

* O codificar un modo útil para guardar entradas SQLVAR no utilizadas.

* COPY "sqlda.cbl" REPLACING --1489-- BY --1--.

01 decimal-sqllen pic s9(4) comp-5.

01 decimal-parts redefines decimal-sqllen.

05 precision pic x.

05 scale pic x.

* Inicializar un elemento de SQLDA de salida

MOVE 1 TO SQLN

MOVE 1 TO SQLD

MOVE SQL-TYP-NDECIMAL TO SQLTYPE(1)

* Longitud = 7 dígitos de precisión y 2 dígitos de escala

MOVE x"07" TO PRECISION.

MOVE x"02" TO SCALE.

MOVE DECIMAL-SQLLEN TO O-SQLLEN(1).

SET SQLDATA(1) TO ADDRESS OF SALARY

SET SQLIND(1) TO ADDRESS OF SAL-IND



FORTRAN

include ’sqldact.f’

integer*2 sqlvar1

parameter ( sqlvar1 = sqlda_header_sz + 0*sqlvar_struct_sz )

C Declarar una SQLDA de salida -- 1 Variable

character out_sqlda(sqlda_header_sz + 1*sqlvar_struct_sz)

character*8 out_sqldaid ! Cabecera

integer*4 out_sqldabc

integer*2 out_sqln

integer*2 out_sqld

integer*2 out_sqltype1 ! Primera variable

integer*2 out_sqllen1

integer*4 out_sqldata1

integer*4 out_sqlind1

integer*2 out_sqlnamel1

character*30 out_sqlnamec1

equivalence( out_sqlda(sqlda_sqldaid_ofs), out_sqldaid )

equivalence( out_sqlda(sqlda_sqldabc_ofs), out_sqldabc )

equivalence( out_sqlda(sqlda_sqln_ofs), out_sqln )

equivalence( out_sqlda(sqlda_sqld_ofs), out_sqld )

equivalence( out_sqlda(sqlvar1+sqlvar_type_ofs), out_sqltype1 )

equivalence( out_sqlda(sqlvar1+sqlvar_len_ofs), out_sqllen1 )

equivalence( out_sqlda(sqlvar1+sqlvar_data_ofs), out_sqldata1 )

equivalence( out_sqlda(sqlvar1+sqlvar_ind_ofs), out_sqlind1 )

equivalence( out_sqlda(sqlvar1+sqlvar_name_length_ofs),

+ out_sqlnamel1 )

equivalence( out_sqlda(sqlvar1+sqlvar_name_data_ofs),

+ out_sqlnamec1 )

C Declarar variables locales para albergar los datos devueltos.

real*8 salary

integer*2 sal_ind

C Inicializar la SQLDA de salida (cabecera)

out_sqldaid = ’OUT_SQLDA’

out_sqldabc = sqlda_header_sz + 1*sqlvar_struct_sz

out_sqln = 1

out_sqld = 1

C Inicializar VAR1

out_sqltype1 = SQL_TYP_NFLOAT

out_sqllen1 = 8

rc = sqlgaddr( %ref(salary), %ref(out_sqldata1) )

rc = sqlgaddr( %ref(sal_ind), %ref(out_sqlind1) )

Nota: El ejemplo anterior se ha escrito para FORTRAN de 32 bits.

En lenguajes que no dan soporte a la asignación dinámica de memoria, se debe

declarar de forma explícita en el lenguaje principal una SQLDA con el número

deseado de elementos SQLVAR. Asegúrese de declarar el número suficiente de

elementos SQLVAR según los requisitos de la aplicación.









Transferencia de datos en un programa de SQL ejecutado

dinámicamente utilizando una estructura SQLDA

Puede obtener una mayor flexibilidad si transfiere datos mediante una SQLDA que

si utiliza listas de variables del lenguaje principal. Por ejemplo, puede utilizar una

SQLDA para transferir datos que no tienen ningún equivalente en el lenguaje

principal, como datos DECIMAL en lenguaje C.

Procedimiento:

Utilice la siguiente tabla como listado de referencias cruzadas que muestra cómo se

relacionan los valores numéricos y los nombres simbólicos.

Tabla 17. Tipos de SQL de SQLDA de DB2. Valores numéricos y nombres simbólicos correspondientes

Tipo de columna SQL

Valor numérico

SQLTYPE Nombre simbólico SQLTYPE1

DATE 384/385 SQL_TYP_DATE / SQL_TYP_NDATE

TIME 388/389 SQL_TYP_TIME / SQL_TYP_NTIME

TIMESTAMP 392/393 SQL_TYP_STAMP / SQL_TYP_NSTAMP

n/d2 400/401 SQL_TYP_CGSTR / SQL_TYP_NCGSTR

BLOB 404/405 SQL_TYP_BLOB / SQL_TYP_NBLOB

CLOB 408/409 SQL_TYP_CLOB / SQL_TYP_NCLOB

DBCLOB 412/413 SQL_TYP_DBCLOB / SQL_TYP_NDBCLOB

VARCHAR 448/449 SQL_TYP_VARCHAR / SQL_TYP_NVARCHAR

CHAR 452/453 SQL_TYP_CHAR / SQL_TYP_NCHAR

LONG VARCHAR 456/457 SQL_TYP_LONG / SQL_TYP_NLONG

n/d3 460/461 SQL_TYP_CSTR / SQL_TYP_NCSTR

VARGRAPHIC 464/465 SQL_TYP_VARGRAPH / SQL_TYP_NVARGRAPH

GRAPHIC 468/469 SQL_TYP_GRAPHIC / SQL_TYP_NGRAPHIC

LONG VARGRAPHIC 472/473 SQL_TYP_LONGRAPH / SQL_TYP_NLONGRAPH

FLOAT 480/481 SQL_TYP_FLOAT / SQL_TYP_NFLOAT

REAL4 480/481 SQL_TYP_FLOAT / SQL_TYP_NFLOAT

DECIMAL5 484/485 SQL_TYP_DECIMAL / SQL_TYP_DECIMAL

INTEGER 496/497 SQL_TYP_INTEGER / SQL_TYP_NINTEGER

SMALLINT 500/501 SQL_TYP_SMALL / SQL_TYP_NSMALL

n/d 804/805 SQL_TYP_BLOB_FILE / SQL_TYPE_NBLOB_FILE

n/d 808/809 SQL_TYP_CLOB_FILE / SQL_TYPE_NCLOB_FILE

n/d 812/813 SQL_TYP_DBCLOB_FILE / SQL_TYPE_NDBCLOB_FILE

n/d 960/961 SQL_TYP_BLOB_LOCATOR / SQL_TYP_NBLOB_LOCATOR

n/d 964/965 SQL_TYP_CLOB_LOCATOR / SQL_TYP_NCLOB_LOCATOR

n/d 968/969 SQL_TYP_DBCLOB_LOCATOR / SQL_TYP_NDBCLOB_LOCATOR

XML 988/989 SQL_TYP_XML / SQL_TYP_XML


Tabla 17. Tipos de SQL de SQLDA de DB2 (continuación). Valores numéricos y nombres simbólicos

correspondientes

Tipo de columna SQL

Valor numérico

SQLTYPE Nombre simbólico SQLTYPE1

Nota: Estos tipos definidos se encuentran en el archivo include sql.h del subdirectorio include del directorio sqllib.

(Por ejemplo, sqllib/include/sql.h para el lenguaje de programación C.)

1. Para el lenguaje de programación COBOL, el nombre SQLTYPE no utiliza el signo de subrayado (_) sino un guión

(-).

2. Es una serie gráfica terminada en nulo.

3. Es una serie de caracteres terminada en nulo.

4. La diferencia entre REAL y DOUBLE en la SQLDA es el valor de la longitud (4 u 8).

5. La precisión está en el primer byte. La escala está en el segundo byte.



v “Descripción de una sentencia SELECT en un programa de SQL ejecutado



159

Proceso de sentencias de SQL interactivas en programas de

SQL ejecutados dinámicamente

Una aplicación que utiliza SQL dinámico se puede escribir de modo que procese

sentencias arbitrarias de SQL. Por ejemplo, si una aplicación acepta sentencias de

SQL del usuario, la aplicación debe ser capaz de ejecutar las sentencias sin

conocimiento previo de las mismas. Los valores desconocidos hasta el momento de

la ejecución se pueden representar mediante marcadores de parámetro, que se

indican mediante signos de interrogación. Los marcadores de parámetro permiten

la interacción entre el usuario y la aplicación y se parecen a las variables del

lenguaje principal para sentencias de SQL estático.

Procedimiento:

Utilice las sentencias PREPARE y DESCRIBE con una estructura SQLDA de modo

que la aplicación pueda determinar el tipo de sentencia de SQL que se ejecutan y

actuar consecuentemente.


v “Determinación del tipo de sentencia en programas de SQL ejecutados





Determinación del tipo de sentencia en programas de SQL

ejecutados dinámicamente

Cuando se prepara una sentencia de SQL, la información sobre el tipo de sentencia

se puede determinar examinando la estructura SQLDA. Esta información se coloca


en la estructura SQLDA en el momento de la preparación de la sentencia con la

cláusula INTO o emitiendo una sentencia DESCRIBE contra una sentencia

preparada anteriormente.

En cualquier caso, el gestor de bases de datos coloca un valor en el campo SQLD

de la estructura SQLDA que indica el número de columnas de la tabla de

resultados generada por la sentencia de SQL. Si el campo SQLD contiene un cero

(0), significa que la sentencia no es una sentencia SELECT. Puesto que la sentencia

ya está preparada, se puede ejecutar inmediatamente mediante la sentencia

EXECUTE.

Si la sentencia contiene marcadores de parámetros, se debe especificar la cláusula

USING. La cláusula USING puede especificar una lista de variables del lenguaje

principal o una estructura SQLDA.

Si el campo SQLD es mayor que cero, significa que la sentencia es una sentencia

SELECT y se debe procesar tal como se describe en las siguientes secciones.



v “Sentencia SELECT INTO” en Consulta de SQL, Volumen 2


Proceso de sentencias SELECT de lista de variables en

programas de SQL ejecutados dinámicamente

Una sentencia SELECT de lista de variables es una sentencia en la que el número y

los tipos de columnas que se tienen que devolver no se conocen en el momento de

la precompilación. En este caso, la aplicación no sabe con antelación las variables

exactas del lenguaje principal que se tienen que declarar para albergar una fila de

la tabla de resultados.

Procedimiento:

Para procesar una sentencia SELECT de lista de variables, codifique la aplicación

de modo que haga lo siguiente:

1. Declare una SQLDA.

Se debe utilizar una estructura SQLDA para procesar las sentencias SELECT de

lista de variables.

2. PREPARE la sentencia mediante la cláusula INTO.

Luego la aplicación determina si la estructura SQLDA declarada tiene

suficientes elementos SQLVAR. Si no es así, la aplicación asigna otra estructura

SQLDA con el número necesario de elementos SQLVAR y emite una sentencia

DESCRIBE adicional mediante el nuevo SQLDA.

3. Asigne los elementos SQLVAR.

Asigne almacenamiento para las variables del lenguaje principal e indicadores

necesarios para cada SQLVAR. Este paso incluye la colocación de las

direcciones asignadas para los datos y variables de indicador en cada elemento

SQLVAR.

4. Procese la sentencia SELECT.

Se asocia un cursor con la sentencia preparada, se abre y las filas se captan

mediante la estructura SQLDA correctamente asignada.








v “Descripción de una sentencia SELECT en un programa de SQL ejecutado





159

Cómo guardar peticiones de SQL procedentes de usuarios

finales

Si los usuarios de la aplicación pueden emitir peticiones de SQL desde la

aplicación, es posible que desee guardar dichas peticiones.

Procedimiento:

Si la aplicación permite a los usuarios guardar sentencias arbitrarias de SQL, las

puede guardar en una tabla con una columna que tenga el tipo VARCHAR, LONG

VARCHAR, CLOB, VARGRAPHIC, LONG VARGRAPHIC o DBCLOB. Tenga en

cuenta que los tipos de datos VARGRAPHIC, LONG VARGRAPHIC y DBCLOB

sólo están disponibles en entornos de juego de caracteres de doble byte (DBCS) y

de Extended UNIX Code (EUC).

Debe guardar los elementos SQL fuente, no las versiones preparadas. Esto significa

que debe recuperar y luego preparar cada sentencia antes de ejecutar la versión

almacenada en la tabla. Básicamente, la aplicación prepara una sentencia de SQL a

partir de una serie de caracteres y ejecuta esta sentencia de forma dinámica.







Ejecución de expresiones XQuery en aplicaciones de SQL

incorporado

Puede almacenar datos XML en las tablas y utilizar aplicaciones de SQL

incorporado para acceder a columnas XML mediante expresiones XQuery. Para

acceder a datos XML, utilice variables del lenguaje principal XML en lugar de

convertir los datos a tipos de datos de carácter o binarios. Si no utiliza las variables

del lenguaje principal XML, la mejor alternativa para acceder a datos XML es

mediante FOR BIT DATA o con tipos de datos BLOB para evitar conversiones de

páginas de códigos.

Requisitos previos:


v Declare las variables del lenguaje principal XML dentro de las aplicaciones de

SQL incorporado.

Restricciones:

v Se debe utilizar un tipo XML para recuperar valores de XML en una sentencia

de SQL estático SELECT INTO.

v Si se utiliza una variable del lenguaje principal CHAR, VARCHAR, CLOB o

BLOB para entrada donde se espera un valor XML, el valor estará sujeto a una

operación de función XMLPARSE con manejo por omisión de espacios en blanco

(STRIP). De lo contrario, se necesita una variable del lenguaje principal XML.

Procedimiento:

Para ejecutar expresiones XQuery en la aplicación de SQL incorporado

directamente, añada al principio de la expresión la palabra clave ″XQUERY″. Para

SQL estático, utilice la función XMLQUERY. Cuando se llama a la función

XMLQUERY, la expresión XQuery no tiene el prefijo ″XQUERY″.

Ejemplo 1: Ejecución de expresiones XQuery directamente en SQL dinámico C y

C++ añadiendo como prefijo la palabra clave ″XQUERY″:

En aplicaciones C y C++, las expresiones XQuery se pueden ejecutar del siguiente

modo:



char stmt[16384];



sprintf( stmt, "XQUERY (10, xs:integer(1) to xs:integer(4))" );

EXEC SQL PREPARE s1 FROM :stmt;

EXEC SQL DECLARE c1 CURSOR FOR s1;

EXEC SQL OPEN c1;

while( sqlca.sqlcode == SQL_RC_OK )

{

EXEC SQL FETCH c1 INTO :xmlblob;

/* Mostrar resultados */

}

EXEC SQL CLOSE c1;

EXEC SQL COMMIT;

Ejemplo 2: Ejecución de expresiones XQuery en SQL estático utilizando la

función XMLQUERY:

Las sentencias de SQL que contienen la función XMLQUERY se pueden preparar

de forma estática, del siguiente modo:





EXEC SQL DECLARE C1 CURSOR FOR SELECT XMLQUERY( ’(10, xs:integer(1) to

xs:integer(4))’ RETURNING SEQUENCE BY REF) from SYSIBM.SYSDUMMY1;

EXEC SQL OPEN c1;

while( sqlca.sqlcode == SQL_RC_OK )


{

EXEC SQL FETCH c1 INTO :xmlblob;

/* Mostrar resultados */

}

EXEC SQL CLOSE c1;

EXEC SQL COMMIT;

Ejemplo 3: Ejecución de expresiones XQuery en aplicaciones de SQL

incorporado COBOL:

En aplicaciones COBOL, las expresiones XQuery se pueden ejecutar del siguiente

modo:


01 stmt pic x(80).

01 xmlBuff USAGE IS SQL TYPE IS XML AS BLOB (10K).


MOVE "XQUERY (10, xs:integer(1) to xs:integer(4))" TO stmt.

EXEC SQL PREPARE s1 FROM :stmt END-EXEC.

EXEC SQL DECLARE c1 CURSOR FOR s1 END-EXEC.

EXEC SQL OPEN c1 USING :host-var END-EXEC.

*Llamar a FETCH y al bucle UPDATE.

Perform Fetch-Loop through End-Fetch-Loop

until SQLCODE does not equal 0.

EXEC SQL CLOSE c1 END-EXEC.

EXEC SQL COMMIT END-EXEC.

Fetch-Loop Section.

EXEC SQL FETCH c1 INTO :xmlBuff END-EXEC.

if SQLCODE not equal 0

go to End-Fetch-Loop.

* Mostrar resultados

End-Fetch-Loop. exit.


v “Almacenamiento binario de valores de variables mediante la cláusula FOR BIT

DATA en aplicaciones de SQL incorporado C y C++” en la página 112

v “Almacenamiento binario de valores de variables mediante la cláusula FOR BIT

DATA en aplicaciones de SQL incorporado COBOL” en la página 129





v “XML serialization” en XML Guide








Suministro de entrada de variables a un SQL ejecutado

dinámicamente mediante marcadores de parámetros

Cómo proporcionar entrada de variables a una sentencia de SQL

ejecutada dinámicamente mediante marcadores de parámetros

Una sentencia de SQL dinámico no puede contener variables del lenguaje

principal, porque la información de las variables del lenguaje principal (tipo de

datos y longitud) sólo está disponible durante la precompilación de la aplicación.

En el momento de la ejecución, la información de las variables del lenguaje

principal no está disponible.

En SQL dinámico, se utilizan marcadores de parámetros en lugar de variables del

lenguaje principal. Los marcadores de parámetros se indican mediante un signo de

interrogación (?)e indican dónde se debe sustituir una variable del lenguaje

principal dentro de una sentencia de SQL.

Procedimiento:

Supongamos que la aplicación utiliza SQL dinámico y que desea que pueda

realizar una operación DELETE. Una serie de caracteres que contenga un marcador

de parámetros puede tener un aspecto parecido al siguiente:

DELETE FROM TEMPL WHERE EMPNO = ?

Cuando se ejecuta esta sentencia, se especifica una variable del lenguaje principal o

una estructura SQLDA mediante la cláusula USING de la sentencia EXECUTE. El

contenido de la variable del lenguaje principal se utiliza cuando se ejecuta la

sentencia.

El marcador de parámetros adopta un tipo de datos y longitud supuestos que

dependen del contexto de su uso dentro de la sentencia de SQL. Si el tipo de datos

de un marcador de parámetros no resulta obvio a partir del contexto de la

sentencia en la que se utiliza, utilice CAST para especificar el tipo. Dicho marcador

de parámetros se considera un a marcador de parámetros tipificado. Los marcadores

de parámetros tipificados se tratan como una variable del lenguaje principal del

tipo determinado. Por ejemplo, la sentencia SELECT ? FROM SYSCAT.TABLES no es

válida porque DB2 no conoce el tipo de la columna de resultados. Sin embargo, la

sentencia SELECT CAST(? AS INTEGER) FROM SYSCAT.TABLES es válida porque cast

indica que el marcador de parámetros representa un INTEGER, de modo que DB2

conoce el tipo de la columna de resultados.

Si la sentencia de SQL contiene más de un marcador de parámetros, la cláusula

USING de la sentencia EXECUTE debe especificar una lista de variables del

lenguaje principal (una para cada marcador de parámetros) o debe identificar una

SQLDA que tenga una entrada SQLVAR para cada marcador de parámetros.

(Observe que para los LOB, existen dos entradas SQLVAR por cada marcador de

parámetros.) La lista de variables del lenguaje principal o entradas SQLVAR se

comparan de acuerdo con el orden de los marcadores de parámetros en la

sentencia y deben tener tipos de datos compatibles.

Nota: El utilizar un marcador de parámetros con SQL dinámico es como utilizar

variables del lenguaje principal con SQL estático. En cualquier caso, el

optimizador no utiliza estadísticas de distribución y es posible que no elija

el mejor plan de acceso.


Las normas que se aplican a marcadores de parámetros se describen con la

sentencia PREPARE.







v “Conversiones entre tipos de datos” en Consulta de SQL, Volumen 1

Ejemplo de marcadores de parámetros en un programa de SQL


Los siguientes ejemplos muestran cómo utilizar marcadores de parámetros en un

programa de SQL dinámico:

v C y C++ (dbuse.sqc/dbuse.sqC)

La función DynamicStmtWithMarkersEXECUTEusingHostVars() del ejemplo de

lenguaje C dbuse.sqc muestra cómo realizar una supresión mediante un

marcador de parámetro con una variable del lenguaje principal:


char hostVarStmt1[50];

short hostVarDeptnumb;


/* preparar la sentencia con un marcador de parámetros */

strcpy(hostVarStmt1, "DELETE FROM org WHERE deptnumb = ?");

EXEC SQL PREPARE Stmt1 FROM :hostVarStmt1;

/* ejecutar la sentencia correspondiente a hostVarDeptnumb = 15 */

hostVarDeptnumb = 15;

EXEC SQL EXECUTE Stmt1 USING :hostVarDeptnumb;

v COBOL (varinp.sqb)

El siguiente ejemplo procede del ejemplo de COBOL varinp.sqb y muestra cómo

utilizar un marcador de parámetros en condiciones de búsqueda y actualización:


01 pname pic x(10).

01 dept pic s9(4) comp-5.

01 st pic x(127).

01 parm-var pic x(5).


move "SELECT name, dept FROM staff

- " WHERE job = ? FOR UPDATE OF job" to st.

EXEC SQL PREPARE s1 FROM :st END-EXEC.


move "Mgr" to parm-var.

EXEC SQL OPEN c1 USING :parm-var END-EXEC

move "Clerk" to parm-var.

move "UPDATE staff SET job = ? WHERE CURRENT OF c1" to st.

EXEC SQL PREPARE s2 from :st END-EXEC.

* llamar a FETCH y al bucle UPDATE.


perform Fetch-Loop thru End-Fetch-Loop

until SQLCODE not equal 0.




página 191


v “dbuse.out -- HOW TO USE A DATABASE (C)”

v “dbuse.sqc -- How to use a database (C)”

v “dbuse.out -- HOW TO USE A DATABASE (C++)”

v “dbuse.sqC -- How to use a database (C++)”

Llamada a procedimientos almacenados en aplicaciones de

SQL incorporado

Llamada a procedimientos almacenados en aplicaciones de SQL

incorporado

Se puede llamar a procedimientos almacenados desde aplicaciones de SQL

incorporado formulando y ejecutando la sentencia CALL con los parámetros y

referencia a procedimiento adecuados. La sentencia CALL se puede ejecutar de

forma estática o dinámica dentro de aplicaciones de SQL incorporado. Sin

embargo, para cada lenguaje de programación hay distintos métodos para ejecutar

este mandato. Independientemente del lenguaje principal, cada variable del

lenguaje principal utilizada en el procedimiento almacenado se tiene que declarar

de modo que coincida con el tipo de datos necesario.

Las aplicaciones cliente y la llamada de rutinas intercambian información con los

procedimientos a través de parámetros y conjuntos de resultados. Los parámetros

correspondientes a procedimientos están definidos por la dirección en que viajan

los datos (la modalidad de parámetro).

Existen tres tipos de parámetros para los procedimientos:

v Parámetros IN: los datos pasados al procedimiento.

v Parámetros OUT: los datos devueltos por el procedimiento.

v Parámetros INOUT: los datos pasados al procedimiento que, durante la ejecución

del mismo, se sustituyen por datos que el procedimiento debe devolver.

La modalidad de los parámetros y sus tipos de datos se definen cuando se registra

un procedimiento con la sentencia CREATE PROCEDURE.


v “Llamada a procedimientos almacenados desde REXX” en la página 172

v “Llamada a procedimientos almacenados en aplicaciones de SQL incorporado C


Llamada a procedimientos almacenados en aplicaciones de SQL

incorporado C y C++

Llamada a procedimientos almacenados en aplicaciones de SQL incorporado C y

C++:


DB2 da soporte al uso de parámetros de entrada, de salida y de entrada y salida

en procedimientos de SQL. Las palabras clave IN, OUT e INOUT en la sentencia

CREATE PROCEDURE indican la modalidad o el uso deseado del parámetro. Los

parámetros IN y OUT se pasan por valor, y los parámetros INOUT se pasan por

referencia.

Cuando se trabaja con aplicaciones C y C++, se puede llamar a un procedimiento

almacenado, INOUT_PARAM, mediante la siguiente sentencia:

EXEC SQL CALL INOUT_PARAM(:inout_median:medianind, :out_sqlcode:codeind,

:out_buffer:bufferind);

donde inout_median, out_sqlcode y out_buffer son variables del lenguaje principal

y medianind, codeind y bufferind son variables de indicadores de nulo.

Nota: También se puede llamar a procedimientos almacenados dinámicamente

preparando una sentencia CALL.


v “Rutinas: Procedimientos” en Desarrollo de SQL y rutinas externas


v “Ejemplos de procedimientos ” en Temas de ejemplos

Llamada a procedimientos almacenados desde REXX

Llamada a procedimientos almacenados desde REXX: El procedimiento

almacenado puede estar escrito en cualquier lenguaje soportado en dicho servidor,

a excepción de REXX en los sistemas AIX. (Las aplicaciones cliente pueden estar

escritas en REXX en los sistemas AIX, pero, al igual que en otros lenguajes, no

pueden llamar a un procedimiento almacenado escrito en REXX en AIX.)


v “Procedimientos almacenados en REXX” en la página 172

Procedimientos almacenados en REXX: La sentencia CALL permite que una

aplicación cliente pase datos a un procedimiento almacenado en un servidor, y

reciba datos del mismo. La interfaz para los datos tanto de entrada como de salida

es una lista de variables del lenguaje principal. Puesto que REXX suele determinar

el tipo y el tamaño de las variables del lenguaje principal en base a su contenido,

las variables que sean sólo de salida y se pasen a CALL se deben inicializar con

datos ficticios, parecidos en tipo y tamaño a la salida esperada.

También se pueden pasar datos a los procedimientos almacenados a través de las

variables SQLDA de REXX, mediante la sintaxis USING DESCRIPTOR de la

sentencia CALL. La lista siguiente muestra cómo se establece la SQLDA. En la

lista, ':value' es la raíz de una variable del lenguaje principal REXX que contiene

los valores necesarios para la aplicación. Para DESCRIPTOR, 'n' es un valor

numérico que indica un elemento sqlvar específico de la SQLDA. Los números que

aparecen a la derecha hacen referencia a las notas que siguen a la lista.

SQLDA de REXX de la parte cliente para procedimientos almacenados que

utilizan la sentencia CALL:

USING DESCRIPTOR

v :value.SQLD 1


v :value.n.SQLTYPE 1

v :value.n.SQLLEN 1

v :value.n.SQLDATA 1 2

v :value.n.SQLDIND 1 2

Notas:

1. Antes de invocar al procedimiento almacenado, la aplicación cliente tiene que

inicializar la variable de REXX con los datos apropiados.

Cuando se ejecuta la sentencia CALL de SQL, el gestor de bases de datos

asigna almacenamiento y recupera el valor de la variable de REXX de la

agrupación de variables de REXX. Para una SQLDA utilizada en una sentencia

CALL, el gestor de bases de datos asigna almacenamiento para los campos

SQLDATA y SQLIND en base a los valores de SQLTYPE y SQLLEN.

En el caso de un procedimiento almacenado REXX (es decir, el propio

procedimiento invocado está escrito en REXX basado en Windows), los datos

pasados por el cliente desde cualquiera de los dos tipos de sentencia CALL o

de la API DARI se colocan en la agrupación de variables de REXX en el

servidor de bases de datos, utilizando los nombres predefinidos siguientes:

SQLRIDA

Nombre predefinido para la variable SQLDA de entrada de REXX

SQLRODA

Nombre predefinido para la variable SQLDA de salida de REXX2. Cuando termina el procedimiento almacenado, el gestor de bases de datos

recupera también el valor de las variables del procedimiento almacenado. Los

valores se devuelven a la aplicación cliente y se colocan en la agrupación de

variables de REXX del cliente.


v “Consideraciones del cliente para llamar a procedimientos almacenados en

REXX” en la página 175

v “Recuperación de valores de precisión y escala (SCALE) de campos decimales de

la SQLDA” en la página 175

v “Consideraciones del servidor para llamar a procedimientos almacenados en

REXX” en la página 175


v “Sentencia CALL” en Consulta de SQL, Volumen 2

Sintaxis de las API para REXX: Utilice la rutina SQLDBS para llamar a las API de

DB2 con la sintaxis siguiente:

CALL SQLDBS ’command string’

Si no puede llamar a una API de DB2® que desea utilizar mediante la rutina

SQLDBS, puede llamar a la API efectuando una llamada al procesador de línea de

mandatos (CLP) de DB2 desde dentro de la aplicación REXX. Sin embargo, puesto

que el CLP de DB2 dirige la salida al dispositivo de salida estándar o a un archivo

especificado, la aplicación REXX no puede acceder directamente a la salida de la

API de DB2 a la que se ha llamado, ni puede tomar fácilmente la determinación de

si la API llamada ha resultado satisfactoria o no. La API SQLDB2 proporciona una

interfaz con el CLP de DB2 que proporciona información directa a la aplicación

REXX sobre el éxito o fracaso de cada API llamada, estableciendo la variable

compuesta SQLCA de REXX después de cada llamada.


Puede utilizar la rutina SQLDB2 para llamar a las API de DB2 utilizando la

sintaxis siguiente:

CALL SQLDB2 ’command string’

donde ’command string’ es una serie que puede procesar el procesador de línea de

mandatos (CLP).

El hecho de llamar a una API de DB2 mediante SQLDB2 es equivalente a llamar

directamente al CLP, excepto en los aspectos siguientes:

v La llamada al ejecutable del CLP se sustituye por la llamada a SQLDB2 (el resto

de opciones y parámetros del CLP se especifican de la misma manera).

v La variable compuesta SQLCA de REXX se establece después de llamar a

SQLDB2, pero no se establece después de llamar al ejecutable del CLP.

v La salida de visualización por omisión del CLP se establece como desactivada

cuando se llama a SQLDB2, mientras que se establece como salida activada

cuando se llama al ejecutable del CLP. Observe que puede activar la salida de

visualización del CLP pasando las opciones +o o −o− a SQLDB2.

Puesto que la única variable de REXX que se establece después de llamar a

SQLDB2 es la SQLCA, sólo debe utilizar esta rutina para llamar a las API de DB2

que no devuelvan datos distintos de la SQLCA y que no estén implementadas

actualmente mediante la interfaz SQLDBS. Así pues, SQLDB2 únicamente soporta

las API de DB2 siguientes:

v Activar base de datos

v Añadir nodo

v Vincular para DB2 Versión 1(1) (2)

v Vincular para DB2 Versión 2 ó 5(1)

v Crear base de datos en nodo

v Eliminar base de datos en nodo

v Verificar eliminación de nodo

v Desactivar base de datos

v Desregistrar

v Cargar(3)

v Cargar consulta

v Precompilar programa(1)

v Revincular paquete(1)

v Redistribuir grupo de particiones de base de datos

v Registrar

v Iniciar gestor de la base de datos

v Detener gestor de la base de datos

Notas sobre las API de DB2 soportadas por SQLDB2:

1. Estos mandatos requieren una sentencia CONNECT a través de la interfaz

SQLDB2. Las conexiones que utilizan la interfaz SQLDB2 no están accesibles

para la interfaz SQLEXEC, y las conexiones que utilizan la interfaz SQLEXEC

no están accesible para la interfaz SQLDB2.

2. Está soportado en las plataformas basadas en Windows® mediante la interfaz

SQLDB2.

3. El parámetro de salida opcional, pLoadInfoOut para la API Cargar no se

devuelve a la aplicación en REXX.

Nota: Aunque la rutina SQLDB2 ha sido pensada para uso únicamente de las API

de DB2 relacionadas anteriormente, también se puede utilizar para otras API


de DB2 que no se soportan a través de la rutina SQLDBS. Alternativamente,

se puede acceder a las API de DB2 a través del CLP desde la aplicación

REXX.



Consideraciones del cliente para llamar a procedimientos almacenados en

REXX: Cuando utilice variables del lenguaje principal en la sentencia CALL,

inicialice cada una de las variables del lenguaje principal con un valor que sea de

un tipo compatible con los datos que se devuelvan a la variable del lenguaje

principal desde el procedimiento del servidor. Debe realizar esta inicialización

aunque el indicador correspondiente sea negativo.

Cuando utilice descriptores, SQLDATA debe estar inicializada y contener datos que

sean de un tipo compatible con los datos que se devuelvan desde el procedimiento

del servidor. Debe realizar esta inicialización aunque el campo SQLIND contenga

un valor negativo.



en la página 72

Consideraciones del servidor para llamar a procedimientos almacenados en

REXX: Asegúrese de que todos los campos SQLDATA y SQLIND (si es de un tipo

anulable) de la SQLRODA de SQLDA de salida predefinida estén inicializados. Por

ejemplo, si SQLRODA.SQLD es 2, los campos siguientes deben contener datos

(aunque los indicadores correspondientes sean negativos y no se pasen datos al

cliente):

v SQLRODA.1.SQLDATA

v SQLRODA.2.SQLDATA



Recuperación de valores de precisión y escala (SCALE) de campos decimales de

la SQLDA: Para recuperar los valores de precisión y escala para campos

decimales de la estructura SQLDA devuelta por el gestor de bases de datos, utilice

los valores sqllen.scale y sqllen.precision cuando inicialice la salida de la

SQLDA en el programa REXX. Por ejemplo:

.

.

.

/* INICIALIZAR UN ELEMENTO DE SQLDA DE SALIDA */

io_sqlda.sqld = 1

io_sqlda.1.sqltype = 485 /* TIPO DE DATOS DECIMAL */

io_sqlda.1.sqllen.scale = 2 /* DÍGITOS A LA DERECHA DE LA COMA DECIMAL */

io_sqlda.1.sqllen.precision = 7 /* ANCHURA DEL DECIMAL */

io_sqlda.1.sqldata = 00000.00 /* FORMATO DE DATOS DE DEFINICIÓN DE AYUDAS */

io_sqlda.1.sqlind = -1 /* SIN DATOS DE ENTRADA */

.

.

.






Lectura de los conjuntos de resultados y desplazamiento por

los mismos en aplicaciones de SQL incorporado

Lectura de los conjuntos de resultados y desplazamiento por los

mismos en aplicaciones de SQL incorporado

Una de las tareas más comunes de un programa de aplicación de SQL incorporado

es recuperar datos. Esta tarea se lleva a cabo utilizando la sentencia select, que es

una forma de consulta que busca filas de tablas de la base de datos que cumplen

con las condiciones de búsqueda especificadas. Si existen dichas filas, los datos se

recuperan y se colocan en variables especificadas en el programa de sistema

principal, donde se pueden utilizar con el fin para el que está diseñado.

Nota: Las aplicaciones de SQL incorporado pueden llamar a procedimientos

almacenados con cualquiera de las implementaciones de procedimientos

almacenados soportadas y pueden recuperar valores de parámetros de salida

y de entrada-salida; sin embargo, las aplicaciones de SQL incorporado no

pueden leer los conjuntos de resultados devueltos por procedimientos

almacenados ni desplazarse por los mismos.

Después de escribir una sentencia select, codifique las sentencias de SQL que

definen el modo en que la información se pasará a la aplicación.

Puede entender el resultado de una sentencia select como una tabla que tiene filas

y columnas, parecida a una tabla de la base de datos. Si sólo se devuelve una fila,

puede distribuir los resultados directamente en variables del lenguaje principal

especificadas por la sentencia SELECT INTO.

Si se devuelve más de una fila, debe utilizar un cursor para captarlas de una en

una. Un cursor es una estructura de control con nombre que es utilizada por un

programa de aplicación para apuntar a una fila específica dentro de un conjunto

ordenado de filas.


v “Ejemplo de un cursor en una aplicación de SQL ejecutada estáticamente” en la

página 186


página 74


v “Declaración y utilización de cursores en aplicaciones de SQL ejecutadas

estáticamente” en la página 184



v “Identificación de valores de SQL nulos con variables de indicador de nulo” en

la página 81







v “spclient.sqc -- Call various stored procedures (C)”

Desplazamiento por datos anteriormente recuperados en


Cuando una aplicación recupera datos de la base de datos, la sentencia FETCH le

permite desplazarse hacia adelante por los datos; sin embargo, no hay ninguna

sentencia de SQL que le permita desplazarse hacia atrás por el conjunto de

resultados (equivalente a una operación FETCH hacia atrás). Sin embargo, la CLI

de DB2 y el controlador DB2 Universal JDBC dan soporte a la operación FETCH

hacia atrás mediante cursores desplazables de sólo lectura.

Procedimiento:

Para aplicaciones de SQL incorporado, puede utilizar las siguientes técnicas para

desplazarse por los datos que se han recuperado:

v Conserve una copia de los datos que se han captado en la memoria de la

aplicación y desplácese por los mismos mediante alguna técnica de

programación.

v Utilice SQL para recuperar de nuevo los datos, normalmente mediante una

segunda sentencia SELECT.


v “Mantenimiento de una copia de datos captados aplicaciones de SQL


v “Recuperación de datos captados por segunda vez en aplicaciones de SQL



v “Cursor positioning rules for SQLFetchScroll() (CLI)” en Call Level Interface Guide

and Reference, Volume 2

v “SQLFetchScroll function (CLI) - Fetch rowset and return data for all bound

columns” en Call Level Interface Guide and Reference, Volume 2

Mantenimiento de una copia de datos captados aplicaciones de

SQL incorporado

En algunas situaciones, puede resultar útil mantener una copia de los datos que

capta la aplicación.

Procedimiento:

Para conservar una copia de los datos, la aplicación puede hacer lo siguiente:

v Guardar los datos captados en almacenamiento virtual.

v Grabar los datos en un archivo temporal (si los datos no caben en

almacenamiento virtual). Un efecto de este enfoque es que un usuario que se

desplace hacia atrás siempre ve exactamente los mismos datos que se han

captado, incluso si mientras tanto una transacción ha modificado los datos de la

base de datos.

v Utilizando un nivel de aislamiento de lectura repetida, los datos que recupera de

una transacción se pueden volver a recuperar cerrando y abriendo un cursor.

Otras aplicaciones no pueden actualizar los datos del conjunto de resultados.

Los niveles de aislamiento y el bloqueo pueden afectar al modo en que los

usuarios actualizan datos.



v “Diferencias en el orden de las filas en tablas de resultados” en la página 179

v “Isolation levels and performance” en Performance Guide




v “Specifying the isolation level” en Performance Guide

Recuperación de datos captados por segunda vez en


La técnica que utilice para recuperar datos por segunda vez dependerá del orden

en el que desee volver a ver los datos.

Procedimiento:

Puede recuperar datos por segunda vez mediante cualquiera de los métodos

siguientes:

v Recuperar datos desde el principio

Para volver a recuperar los datos desde el principio de la tabla de resultados,

cierre el cursor activo y vuélvalo a abrir. Esta acción coloca el cursor al principio

de la tabla de resultados. Pero, a no ser que la aplicación retenga bloqueos en la

tabla, es posible que otros la hayan modificado, de modo que puede que la que

era la primera fila de la tabla de resultados ya no lo sea.

v Recuperar datos desde el medio

Para recuperar datos por segunda vez desde algún punto del medio de la tabla

de resultados, ejecute una segunda sentencia SELECT y declare un segundo

cursor en la sentencia. Por ejemplo, supongamos que la primera sentencia

SELECT era la siguiente:

SELECT * FROM DEPARTMENT

WHERE LOCATION = 'CALIFORNIA'

ORDER BY DEPTNO

Ahora, supongamos que desea volver a las filas que empiezan con DEPTNO =

'M95' y captar de forma secuencial desde dicho punto. Codifique lo siguiente:



AND DEPTNO >= 'M95'

ORDER BY DEPTNO

Esta sentencia coloca el cursor donde desea.

v Recuperar datos en orden inverso

El valor por omisión consiste en ordenar las filas en orden ascendente. Si sólo

hay una fila para cada valor de DEPTNO, la siguiente sentencia especifica un

orden ascendente exclusivo de filas:



ORDER BY DEPTNO

Para recuperar las mismas filas en orden inverso, especifique que el orden debe

ser descendente, como en la siguiente sentencia:



ORDER BY DEPTNO DESC


Un cursor de la segunda sentencia recupera filas exactamente en el orden

inverso al de un cursor de la primera sentencia. El orden de recuperación sólo se

garantiza si la primera sentencia especifica una secuencia de orden exclusiva.

Para recuperar filas en orden inverso, puede resultar útil tener dos índices en la

columna DEPTNO, uno en orden ascendente y el otro en orden descendente.


v “Diferencias en el orden de las filas en tablas de resultados” en la página 179






v “Colocación de un cursor en una fila con un determinado valor de columna” en

la página 183

Diferencias en el orden de las filas en tablas de resultados

Las filas de varias tablas correspondientes a la misma sentencia SELECT pueden

no visualizarse en el mismo orden. El gestor de bases de datos no tiene en cuenta

el orden de las filas como algo significativo a no ser que la sentencia SELECT

utilice ORDER BY. Por lo tanto, si hay varias filas con el mismo valor DEPTNO,

puede que la segunda sentencia SELECT las recupere en un orden distinto al de la

primera. La única garantía es que todas estarán en orden por número de

departamento, tal como solicita la cláusula ORDER BY DEPTNO.

La diferencia en el orden se puede producir aunque ejecute la misma sentencia de

SQL, con las mismas variables del lenguaje principal, por segunda vez. Por

ejemplo, las estadísticas del catálogo se podrían haber actualizado entre

ejecuciones, o se podrían hacer creado o eliminado índices. Entonces podría

ejecutar de nuevo la sentencia SELECT.

Es más probable que el orden cambie si la segunda sentencia SELECT tiene un

predicado que la primera no tenía; el gestor de bases de datos podría elegir utilizar

un índice en el nuevo predicado. Por ejemplo, podría elegir un índice en LOCATION

para la primera sentencia del ejemplo y un índice en DEPTNO para la segunda.

Puesto que las filas se captan en orden por la clave de índice, el segundo orden no

es necesariamente igual al primero.

De nuevo, al ejecutar dos sentencias SELECT parecidas se puede producir un

orden diferente de filas, aunque no se haya producido ningún cambio en las

estadísticas ni se haya creado ni eliminado ningún índice. En el ejemplo, si hay

varios valores diferentes de LOCATION, el gestor de bases de datos podría elegir un

índice en LOCATION para ambas sentencias. Si se cambia el valor de DEPTNO en la

segunda sentencia por lo siguiente, el gestor de bases de datos podría elegir un

índice en DEPTNO:



AND DEPTNO >= 'Z98'

ORDER BY DEPTNO

Debido a la sutil relación entre el formato de una sentencia de SQL y los valores de

dicha sentencia, nunca dé por supuesto que dos sentencias de SQL diferentes


vayan a devolver filas en el mismo orden, a no ser que el orden se determine de

forma exclusiva mediante una cláusula ORDER BY.


v “Lectura de los conjuntos de resultados y desplazamiento por los mismos en





Actualización de datos anteriormente recuperados en


Para desplazarse hacia atrás y actualizar datos recuperados previamente, puede

utilizar una combinación de las técnicas que se utilizan para desplazarse a través

de datos recuperados previamente y para actualizar datos recuperados.

Procedimiento:

Para actualizar datos recuperados previamente, puede hacer una de estas dos

cosas:

v Si tiene un segundo cursor en los datos que se tienen que actualizar y la

sentencia SELECT no utiliza ninguno de los elementos restringidos, puede

utilizar la sentencia UPDATE controlada por el cursor. Nombre el segundo

cursor en la cláusula WHERE CURRENT OF.

v En otros casos, utilice UPDATE con una cláusula WHERE que nombre todos los

valores de la fila o especifique la clave primaria de la tabla. Puede ejecutar una

sentencia varias veces con distintos valores de las variables.



página 186


la página 187


v “Desplazamiento por datos anteriormente recuperados en aplicaciones de SQL


v “Actualización y supresión de datos recuperados en una aplicación de SQL

ejecutada estáticamente” en la página 188





Selección de varias filas mediante un cursor

Selección de varias filas utilizando un cursor en aplicaciones de SQL

incorporado: Para permitir que una aplicación recupere un conjunto de filas, SQL

utiliza un mecanismo denominado un cursor.

Para ayudarle a comprender el concepto de un cursor, supongamos que el gestor

de bases de datos crea una tabla de resultados que contenga todas las filas


recuperadas al ejecutar una sentencia SELECT. Un cursor permite que las filas

procedentes de la tabla de resultados estén disponibles para una aplicación,

identificando o haciendo referencia a una fila actual de esta tabla. Cuando se utiliza

un cursor, una aplicación puede recuperar cada fila secuencialmente de la tabla de

resultados hasta que se encuentra una condición de fin de datos, es decir, se

alcanza la condición NOT FOUND, SQLCODE +100 (SQLSTATE 02000). El

conjunto de filas obtenido como resultado de ejecutar la sentencia SELECT puede

constar de cero, una o más filas, en función del número de filas que cumplan con

la condición de búsqueda.

Procedimiento:

Los pasos a seguir para procesar un cursor son los siguientes:

1. Especifique el cursor utilizando una sentencia DECLARE CURSOR.

2. Realice la consulta y cree la tabla de resultados utilizando la sentencia OPEN.

3. Recupere filas de una en una utilizando la sentencia FETCH.

4. Procese las filas con las sentencias DELETE o UPDATE (si hace falta).

5. Termine el cursor utilizando la sentencia CLOSE.

Una aplicación puede utilizar varios cursores simultáneamente. Cada cursor

necesita su propio conjunto de sentencias DECLARE CURSOR, OPEN, CLOSE y

FETCH.



página 186






Tipos de cursores y consideraciones sobre unidad de trabajo en aplicaciones de

SQL incorporado: Los cursores se dividen en tres categorías:

Sólo lectura

Las filas del cursor sólo se pueden leer, no actualizar. Los cursores de sólo

lectura se utilizan cuando una aplicación sólo va a leer datos, no a

modificarlos. Un cursor se considera de sólo lectura si se basa en una

sentencia select de sólo lectura. Consulte la descripción sobre cómo

actualizar y recuperar datos correspondientes a normas para sentencias

select que definen tablas de resultados no actualizables.

Puede haber ventajas en cuanto a rendimiento para cursores de sólo

lectura. Si se determina que un cursor es de sólo lectura y utiliza un nivel

de aislamiento de lectura repetitiva, se siguen obteniendo y manteniendo

bloqueos de lectura repetitiva en las tablas del sistema que necesita la

unidad de trabajo. Por lo tanto, es importante que las aplicaciones emitan

periódicamente sentencias COMMIT, incluso para cursores de sólo lectura.

Actualizables

Las filas del cursor se pueden actualizar. Los cursores actualizables se

utilizan cuando una aplicación modifica datos a medida que se captan las

filas en el cursor. La consulta especificada sólo puede hacer referencia a

una tabla o vista. La consulta también debe incluir la cláusula FOR


UPDATE, nombrando cada columna que se va a actualizar (a no ser que se

utilice la opción de precompilación LANGLEVEL MIA).

Ambiguos

No se puede determinar si el cursor es actualizable o de sólo lectura a

partir de su definición o contexto. Esta situación puede producirse cuando

se encuentra una sentencia de SQL dinámico que se podría utilizar para

cambiar un cursor que de otro modo se consideraría de sólo lectura.

Un cursor ambiguo se trata como de sólo lectura si se especifica la opción

BLOCKING ALL al precompilar o vincular. De lo contrario, el cursor se

considera actualizable.

Nota: Los cursores que se procesan de forma dinámica siempre son

ambiguos.

En función de cómo se declaren los cursores, las acciones de una operación

COMMIT o ROLLBACK varían para los cursores basados en las siguientes

declaraciones:

Opción WITH HOLD

Si una aplicación completa una unidad de trabajo emitiendo una sentencia

COMMIT, el gestor de bases de datos cierra todos los cursores abiertos,

excepto aquellos declarados utilizando la opción WITH HOLD.

Un cursor declarado con la opción WITH HOLD mantiene los recursos a

los que accede en varias unidades de trabajo. El efecto exacto de declarar

un cursor WITH HOLD depende del modo en que finaliza la unidad de

trabajo:

v Si la unidad de trabajo finaliza con una sentencia COMMIT, los cursores

definidos con WITH HOLD permanecen abiertos (OPEN). El cursor se

coloca antes de la siguiente fila lógica de la tabla de resultados. Además,

las sentencias preparadas que hacen referencia a cursores OPEN

definidos con WITH HOLD se retienen. Sólo las peticiones FETCH y

CLOSE asociadas con un determinado cursor son válidas

inmediatamente después de la sentencia COMMIT. Las sentencias

UPDATE WHERE CURRENT OF y DELETE WHERE CURRENT OF

sólo son válidas para filas captadas dentro de la misma unidad de

trabajo.

Nota: Si un paquete se vuelve a vincular durante una unidad de trabajo,

todos los cursores retenidos se cierran.

v Si la unidad de trabajo finaliza con una sentencia ROLLBACK, todos los

cursores abiertos se cierran, todos los bloqueos adquiridos durante la

unidad de trabajo se liberan y todas las sentencias preparadas que

dependen del trabajo realizado en dicha unidad se eliminan.

Por ejemplo, supongamos que la tabla TEMPL contiene 1.000 entradas.

Desea actualizar la columna salary correspondiente a todos los empleados,

y espera emitir una sentencia COMMIT cada vez que actualiza 100 filas.

1. Declare el cursor utilizando la opción WITH HOLD:

EXEC SQL DECLARE EMPLUPDT CURSOR WITH HOLD FOR

SELECT EMPNO, LASTNAME, PHONENO, JOBCODE, SALARY

FROM TEMPL FOR UPDATE OF SALARY

2. Abra el cursor y recupere datos de la tabla de resultados, fila a fila:


EXEC SQL OPEN EMPLUPDT

.

.

.

EXEC SQL FETCH EMPLUPDT

INTO :upd_emp, :upd_lname, :upd_tele, :upd_jobcd, :upd_wage,

3. Cuando desee actualizar o suprimir una fila, utilice una sentencia

UPDATE o DELETE utilizando la opción WHERE CURRENT OF. Por

ejemplo, para actualizar la fila actual, el programa puede emitir:

EXEC SQL UPDATE TEMPL SET SALARY = :newsalary

WHERE CURRENT OF EMPLUPDT

4. Después de emitir una sentencia COMMIT, debe emitir una sentencia

FETCH antes de poder actualizar otra fila.

Debe incluir código en la aplicación para detectar y manejar un SQLCODE

-501 (SQLSTATE 24501), que se puede devolver en una sentencia FETCH o

CLOSE si la aplicación:

v Utiliza cursores declarados WITH HOLD.

v Ejecuta más de una unidad de trabajo y deja un cursor WITH HOLD

abierto en los límites de la unidad de trabajo (COMMIT WORK).

Si una aplicación invalida su paquete eliminando una tabla de la que

depende, el paquete se vuelve a vincular de forma dinámica. En este caso,

se devuelve un SQLCODE -501 (SQLSTATE 24501) para una sentencia

FETCH o CLOSE porque el gestor de bases de datos cierra el cursor. El

modo de manejar un SQLCODE -501 (SQLSTATE 24501) en esta situación

depende de si desea captar filas desde el cursor:

v Si desea captar filas desde el cursor, abra el cursor y luego ejecute la

sentencia FETCH. Sin embargo, tenga en cuenta que la sentencia OPEN

vuelve a colocar el cursor al principio. La posición anterior retenida en

la sentencia COMMIT WORK se pierde.

v Si no desea captar filas desde el cursor, no emita más peticiones SQL

contra el cursor.

Opción WITH RELEASE

Cuando una aplicación cierra un cursor utilizando la opción WITH

RELEASE, DB2 intenta liberar todos los bloqueos de lectura (READ) que el

cursor sigue reteniendo. El cursor sólo continuará reteniendo bloqueos de

grabación (WRITE). Si la aplicación cierra el cursor sin utilizar la opción

RELEASE, los bloqueos READ y WRITE se liberarán cuando finalice la

unidad de trabajo.






Colocación de un cursor en una fila con un determinado valor de columna: Si

tiene que colocar el cursor al final de una tabla, puede utilizar una sentencia de

SQL para colocarlo.

Procedimiento:


Utilice cualquiera de los ejemplos siguientes como método para colocar un cursor

mediante clasificación:

v El gestor de bases de datos no garantiza un orden en los datos almacenados en

una tabla; por lo tanto, el final de una tabla no está definido. Sin embargo, el

orden se define en el resultado de una sentencia de SQL:


ORDER BY DEPTNO DESC

v La sentencia siguiente coloca el cursor en la fila que tiene el valor de DEPTNO más

alto:


WHERE DEPTNO =

(SELECT MAX(DEPTNO) FROM DEPARTMENT)

Sin embargo, observe que, si hay varias filas con el mismo valor, el cursor se

coloca en la primera de ellas.



159



Declaración y utilización de cursores en aplicaciones de SQL ejecutadas

estáticamente: Se debe utilizar la sentencia DECLARE CURSOR para declarar un

cursor, especificar un nombre para el cursor y especificar la consulta que define el

conjunto de resultados asociado al cursor. Se hace referencia al nombre

especificado en sentencias OPEN, FETCH y CLOSE posteriores. La consulta es

cualquier sentencia select válida.

Restricciones:

La declaración de un cursor puede realizarse en cualquier lugar dentro de una

aplicación de SQL incorporado; sin embargo, debe aparecer antes de que se haga

referencia al mismo en otras sentencias de SQL.

Procedimiento:

Utilice la sentencia DECLARE para definir el cursor. La tabla siguiente contiene

ejemplos correspondientes a los lenguajes principales soportados:

Tabla 18. Declaraciones de cursor por lenguaje principal


C y C++ EXEC SQL DECLARE C1 CURSOR FOR

SELECT PNAME, DEPT FROM STAFF

WHERE JOB=:host_var;

COBOL EXEC SQL DECLARE C1 CURSOR FOR

SELECT NAME, DEPT FROM STAFF

WHERE JOB=:host-var END-EXEC.

FORTRAN EXEC SQL DECLARE C1 CURSOR FOR

+ SELECT NAME, DEPT FROM STAFF

+ WHERE JOB=:host_var









v “Sentencia DECLARE CURSOR” en Consulta de SQL, Volumen 2


v “Sentencia OPEN” en Consulta de SQL, Volumen 2

Declaración y utilización de cursores en una aplicación de SQL ejecutada

dinámicamente: Procesar un cursor de forma dinámica es casi idéntico a

procesarlo mediante SQL estático. Cuando se declara un cursor, se asocia con una

consulta. Utilizando la sentencia FETCH, el cursor se coloca en la siguiente fila de

la tabla de resultados y asigna los valores de dicha fila a variables del lenguaje

principal.

En SQL estático, la consulta es una sentencia SELECT en formato de texto,

mientras que en SQL dinámico la consulta se asocia con un nombre de sentencia

asignado en una sentencia PREPARE. Cualquier variable del lenguaje principal a la

que se haga referencia se representa mediante marcadores de parámetros.

La principal diferencia entre un cursor estático y uno dinámico es que un cursor

estático se prepara en el momento de la precompilación y un cursor dinámico se

prepara en el tiempo de ejecución. Además, las variables del lenguaje principal a

las que se hace referencia en la consulta están representadas mediante marcadores

de parámetros, los cuales se sustituyen por variables del lenguaje principal de

tiempo de ejecución cuando se abre el cursor.

Procedimiento:

Utilice los ejemplos que se muestran en la tabla siguiente cuando codifique

cursores para un programa de SQL dinámico:

Tabla 19. Sentencia declare asociada con una sentencia SELECT dinámica


C/C++

strcpy( prep_string, "SELECT tabname FROM syscat.tables"

"WHERE tabschema = ?" );

EXEC SQL PREPARE s1 FROM :prep_string;


EXEC SQL OPEN c1 USING :host_var;

COBOL

MOVE "SELECT TABNAME FROM SYSCAT.TABLES WHERE TABSCHEMA = ?"

TO PREP-STRING.

EXEC SQL PREPARE S1 FROM :PREP-STRING END-EXEC.

EXEC SQL DECLARE C1 CURSOR FOR S1 END-EXEC.

EXEC SQL OPEN C1 USING :host-var END-EXEC.

FORTRAN

prep_string = ’SELECT tabname FROM syscat.tables WHERE tabschema = ?’

EXEC SQL PREPARE s1 FROM :prep_string

EXEC SQL DECLARE c1 CURSOR FOR s1

EXEC SQL OPEN c1 USING :host_var

REXX

prep_string = "SELECT TABNAME FROM SYSCAT.TABLES WHERE TABSCHEMA = ?"

CALL SQLEXEC ’PREPARE S1 FROM :prep_string’;

CALL SQLEXEC ’DECLARE C1 CURSOR FOR S1’;

CALL SQLEXEC ’OPEN C1 USING :schema_name’;




la página 187





v “Sentencia DECLARE CURSOR” en Consulta de SQL, Volumen 2


v “Sentencia OPEN” en Consulta de SQL, Volumen 2


Ejemplo de un cursor en una aplicación de SQL ejecutada estáticamente: Los

ejemplos tut_read.sqc en C, tut_read.sqC/sqx en C++ y cursor.sqb en COBOL

muestran cómo declarar un cursor, abrir el cursor, captar filas de la tabla y cerrar

el cursor.

Puesto que REXX no da soporte a SQL estático, no se proporciona ningún ejemplo.

v C y C++

El ejemplo tut_read muestra una sentencia select básica de una tabla que utiliza

un cursor. Por ejemplo:

/* declarar cursor */

EXEC SQL DECLARE c1 CURSOR FOR

SELECT deptnumb, deptname FROM org WHERE deptnumb < 40;

/* abrir cursor */

EXEC SQL OPEN c1 ;

/* captar cursor */

EXEC SQL FETCH c1 INTO :deptnumb, :deptname;

while (sqlca.sqlcode != 100)

{

printf(" %8d %-14s\n", deptnumb, deptname);

EXEC SQL FETCH c1 INTO :deptnumb, :deptname;

}

/* cerrar cursor */

EXEC SQL CLOSE c1;

v COBOL

El ejemplo cursor muestra un ejemplo de cómo recuperar datos de una tabla

utilizando un cursor con una sentencia de SQL estático. Por ejemplo:

* Declarar un cursor


SELECT name, dept FROM staff

WHERE job=’Mgr’ END-EXEC.

* Abrir el cursor

EXEC SQL OPEN c1 END-EXEC.

* Captar filas de la tabla ’staff’



* Cerrar el cursor


move "CLOSE CURSOR" to errloc.






página 191







v “cursor.sqb -- How to update table data with cursor statically (IBM COBOL)”

Ejemplo de un cursor en una aplicación de SQL ejecutada dinámicamente: Una

sentencia de SQL dinámico se puede preparar para su ejecución con la sentencia

PREPARE y se puede ejecutar con la sentencia EXECUTE o con la sentencia

DECLARE CURSOR.

PREPARE con EXECUTE

El siguiente ejemplo muestra cómo se puede preparar una sentencia de SQL

dinámico para su ejecución con la sentencia PREPARE y ejecutar con la sentencia

EXECUTE:

v C y C++ (dbuse.sqc/dbuse.sqC):

El siguiente ejemplo procede del ejemplo dbuse:


char hostVarStmt[50];


strcpy(hostVarStmt, "DELETE FROM org WHERE deptnumb = 15");

EXEC SQL PREPARE Stmt FROM :hostVarStmt;

EXEC SQL EXECUTE Stmt;

PREPARE con DECLARE CURSOR

Los ejemplos siguientes muestran cómo se puede preparar una sentencia de SQL

dinámico para su ejecución con la sentencia PREPARE y ejecutar con la sentencia

DECLARE CURSOR:

v C


char st[80];

char parm_var[19};


strcpy( st, "SELECT tabname FROM syscat.tables" );

strcat( st, " WHERE tabname <> ? ORDER BY 1" );

EXEC SQL PREPARE s1 FROM :st;


strcpy( parm_var, "STAFF" );

EXEC SQL OPEN c1 USING :parm_var;

v COBOL (dynamic.sqb)

El siguiente ejemplo procede del ejemplo dynamic.sqb:


01 st pic x(80).

01 parm-var pic x(18).



move "SELECT TABNAME FROM SYSCAT.TABLES ORDER BY 1 WHERE TABNAME <> ?" to st.

EXEC SQL PREPARE s1 FROM :st END-EXEC.


move "STAFF" to parm-var.

EXEC SQL OPEN c1 USING :parm-var END-EXEC.

EXECUTE IMMEDIATE

También puede preparar y ejecutar una sentencia de SQL dinámico con la

sentencia EXECUTE IMMEDIATE (excepto para las sentencias SELECT que

devuelven más de una fila).

v C y C++ (dbuse.sqc/dbuse.sqC)

El siguiente ejemplo procede de la función DynamicStmtEXECUTE_IMMEDIATE() del

ejemplo dbuse:


char stmt1[50];


strcpy(stmt1, "CREATE TABLE table1(col1 INTEGER)");

EXEC SQL EXECUTE IMMEDIATE :stmt1;



página 191


v “dbuse.sqc -- How to use a database (C)”

v “dbuse.out -- HOW TO USE A DATABASE (C)”

v “dbuse.out -- HOW TO USE A DATABASE (C++)”

v “dbuse.sqC -- How to use a database (C++)”

Actualización y supresión de datos recuperados en una

aplicación de SQL ejecutada estáticamente

Se puede actualizar y suprimir la fila a la que hace referencia un cursor. Para que

una fila se pueda actualizar, la consulta correspondiente al cursor no debe ser de

sólo lectura.

Procedimiento:

Para actualizar con un cursor, utilice la cláusula WHERE CURRENT OF en una

sentencia UPDATE. Utilice la cláusula FOR UPDATE para indicar al sistema que

desea actualizar algunas columnas de la tabla de resultados. Puede especificar una

columna en la cláusula FOR UPDATE sin que esté en fullselect; por lo tanto, puede

actualizar columnas que no recupera explícitamente el cursor. Si la cláusula FOR

UPDATE se especifica sin nombres de columna, se considera que todas las

columnas de la tabla o vista identificada en la primera cláusula FROM de fullselect

externo se pueden actualizar. No nombre más columnas de las que necesita en la

cláusula FOR UPDATE. En algunos casos, si se nombran columnas adicionales en

la cláusula FOR UPDATE, es posible que DB2 sea menos eficiente al acceder a los

datos.


La supresión con un cursor se realiza utilizando la cláusula WHERE CURRENT OF

en una sentencia DELETE. En general, la cláusula FOR UPDATE no se necesita

para la supresión de la fila actual de un cursor. La única excepción se produce

cuando se utiliza SQL dinámico para la sentencia SELECT o la sentencia DELETE

en una aplicación que se ha precompilado con el valor SAA1 para LANGLEVEL y

se ha vinculado con BLOCKING ALL. En este caso, se necesita una cláusula FOR

UPDATE en la sentencia SELECT.

La sentencia DELETE hace que la fila a la que hace referencia el cursor se suprima.

Esta supresión deja el cursor colocado antes de la siguiente fila y se debe emitir una

sentencia FETCH antes de que se puedan realizar operaciones WHERE CURRENT

OF adicionales contra el cursor.






v “Consultas de SQL” en Consulta de SQL, Volumen 1

v “Sentencia UPDATE” en Consulta de SQL, Volumen 2

v “Sentencia DELETE” en Consulta de SQL, Volumen 2

Ejemplo de captación en un programa de SQL ejecutado

estáticamente

En el siguiente ejemplo se efectúa una selección en una tabla utilizando un cursor,

se abre el cursor y se captan filas de la tabla. Para cada fila captada, el programa

decide, según criterios sencillos, si la fila se debe suprimir o actualizar.

El lenguaje REXX no da soporte a SQL estático, así que no se proporciona ningún

ejemplo.

v C y C++ (tut_mod.sqc/tut_mod.sqC)

El siguiente ejemplo procede del ejemplo tut_mod. En este ejemplo se efectúa

una selección en una tabla utilizando un cursor, se abre el cursor, se captan, se

actualizan o se suprimen filas de la tabla y luego se cierra el cursor.

EXEC SQL DECLARE c1 CURSOR FOR SELECT * FROM staff WHERE id >= 310;

EXEC SQL OPEN c1;

EXEC SQL FETCH c1 INTO :id, :name, :dept, :job:jobInd, :years:yearsInd, :salary,

:comm:commInd;

El ejemplo tbmod es una versión más larga del ejemplo tut_mod y muestra casi

todos los casos posibles de modificación de datos de la tabla.

v COBOL (openftch.sqb)

El siguiente ejemplo procede del ejemplo openftch. En este ejemplo se efectúa

una selección en una tabla utilizando un cursor, se abre el cursor y se captan

filas de la tabla.


SELECT name, dept FROM staff

WHERE job=’Mgr’

FOR UPDATE OF job END-EXEC.

EXEC SQL OPEN c1 END-EXEC


* llamar a FETCH y al bucle UPDATE/DELETE.






página 191


página 186







v “openftch.sqb -- How to modify table data using cursor statically (IBM COBOL)”

v “tbmod.sqc -- How to modify table data (C)”

v “tbmod.sqC -- How to modify table data (C++)”

Recuperación de mensajes de error en aplicaciones de SQL

incorporado

Información de error en los campos SQLCODE, SQLSTATE y

SQLWARN

La información de error se devuelve en los campos SQLCODE y SQLSTATE de la

estructura SQLCA, que se actualiza tras cada sentencia de SQL ejecutable y tras la

mayoría de las llamadas a API del gestor de bases de datos.

Un archivo fuente que contiene sentencias de SQL ejecutables puede proporcionar

al menos una estructura SQLCA con el nombre sqlca. La estructura SQLCA se

define en el archivo include SQLCA. Los archivos fuente sin sentencias de SQL

incorporado, pero que llaman a las API del gestor de bases de datos, también

pueden proporcionar una o más estructuras SQLCA, pero sus nombres son

arbitrarios.

Si la aplicación cumple con el estándar FIPS 127-2, puede declarar SQLSTATE y

SQLCODE como variables del lenguaje principal para aplicaciones C, C++, COBOL

y FORTRAN, en lugar de utilizar la estructura SQLCA.

Un valor SQLCODE igual a 0 significa una ejecución satisfactoria (con posibles

condiciones de aviso SQLWARN). Un valor positivo significa que la sentencia se ha

ejecutado satisfactoriamente pero con un aviso, como el truncamiento de una

variable del lenguaje principal. Un valor negativo significa que se ha producido

una condición de error.

Un campo adicional, SQLSTATE, contiene un código de error estandarizado

coherente con otros productos de bases de datos de IBM y con otros gestores de

bases de datos que cumplen con SQL92. En la práctica, es conveniente utilizar


valores SQLSTATE cuando le preocupe la portabilidad, pues los valores SQLSTATE

son utilizados por muchos gestores de bases de datos.

El campo SQLWARN contiene una matriz de indicadores de aviso, incluso si

SQLCODE es cero. El primer elemento de la matriz SQLWARN, SQLWARN0,

contiene un blanco si todos los demás elementos están en blanco. SQLWARN0

contiene una W si al menos uno de los otros elementos contiene un carácter de

aviso.

Nota: Si desea desarrollar aplicaciones que acceden a varios servidores RDBMS de

IBM, debe:

v Si es posible, hacer que las aplicaciones comprueben SQLSTATE en lugar

de SQLCODE.

v Si la aplicación va a utilizar DB2 Connect, considerar la posibilidad de

utilizar el recurso de correlación que proporciona DB2 Connect para

correlacionar conversiones de SQLCODE entre bases de datos distintas.



página 191





en la página 122






v “Estructura de datos SQLCA” en Consulta de las API administrativas

Recuperación de mensajes de error en aplicaciones de SQL

incorporado

En función del lenguaje en el que esté escrita la aplicación, debe utilizar un

método u otro para recuperar información de error:

v Las aplicaciones C, C++ y COBOL pueden utilizar la API GET ERROR

MESSAGE para obtener la información correspondiente relacionada con el

SQLCA que se ha pasado.

Ejemplo de C: el procedimiento SqlInfoPrint de UTILAPI.C

/******************************************************************************

** 1.1 - SqlInfoPrint - imprime información de diagnóstico en la pantalla.

**

******************************************************************************/

int SqlInfoPrint( char * appMsg,

struct sqlca * pSqlca,

int line,

char * file )

{ int rc = 0;

char sqlInfo[1024];

char sqlInfoToken[1024];

char sqlstateMsg[1024];

char errorMsg[1024];


if (pSqlca->sqlcode != 0 && pSqlca->sqlcode != 100)

{ strcpy(sqlInfo, "");

if( pSqlca->sqlcode < 0)

{ sprintf( sqlInfoToken, "\n---- error report ----\n");

strcat( sqlInfo, sqlInfoToken);

}

else

{ sprintf( sqlInfoToken, "\n---- warning report ----\n");


} /* endif */

sprintf( sqlInfoToken, " app. message = %s\n", appMsg);


sprintf( sqlInfoToken, " line = %d\n", line);


sprintf( sqlInfoToken, " file = %s\n", file);


sprintf( sqlInfoToken, " SQLCODE = %ld\n", pSqlca->sqlcode);


/* obtener mensaje de error */

rc = sqlaintp( errorMsg, 1024, 80, pSqlca);

/* código de retorno es la longitud de la serie errorMsg */

if( rc > 0)

{ sprintf( sqlInfoToken, "%s\n", errorMsg);


}

/* obtener mensaje SQLSTATE */

rc = sqlogstt( sqlstateMsg, 1024, 80, pSqlca->sqlstate);

if (rc == 0)

{ sprintf( sqlInfoToken, "%s\n", sqlstateMsg);


}

if( pSqlca->sqlcode < 0)

{ sprintf( sqlInfoToken, "--- end error report ---\n");


printf("%s", sqlInfo);

return 1;

}

else

{ sprintf( sqlInfoToken, "--- fin informe avisos ---\n");


printf("%s", sqlInfo);

return 0;

} /* endif */

} /* endif */

return 0;

}

Ejemplo en COBOL: de CHECKERR.CBL

********************************

* Llamada a API GET ERROR MESSAGE *

********************************

call "sqlgintp" using

by value buffer-size

by value line-width

by reference sqlca

by reference error-buffer

returning error-rc.

************************

* GET SQLSTATE MESSAGE *

************************

call "sqlggstt" using

by value buffer-size


by value line-width

by reference sqlstate

by reference state-buffer

returning state-rc.

if error-rc is greater than 0

display error-buffer.

if state-rc is greater than 0

display state-buffer.

if state-rc is less than 0

display "código de retorno de GET SQLSTATE =" state-rc.

if SQLCODE is less than 0

display "--- fin informe errores ---"

go to End-Prog.

display "--- fin informe errores ---"

display "CONTINUANDO PROGRAMA CON AVISOS".

v Las aplicaciones REXX utilizan el procedimiento CHECKERR.

/****** CHECKERR - Comprobar SQLCODE *****/

CHECKERR:

arg errloc

if ( SQLCA.SQLCODE = 0 ) then

return 0

else do

say ’--- informe de errores ---’

say ’Se ha producido un ERROR:’ errloc

say ’SQLCODE :’ SQLCA.SQLCODE

/*********************\

* GET ERROR MESSAGE *

\*********************/

call SQLDBS ’GET MESSAGE INTO :errmsg LINEWIDTH 80’

say errmsg

say ’--- fin informe errores ---’

if (SQLCA.SQLCODE < 0 ) then

exit

else do

say ’AVISO - CONTINUANDO PROGRAMA CON ERRORES’

return 0

end

end

return 0





en la página 122




v “API sqlaintp - Obtener mensaje de error” en Consulta de las API administrativas


Consideraciones sobre las rutinas de lista de salida

No utilice SQL ni llamadas a API de DB2 en rutinas de lista de salida. Tenga en

cuenta que no puede desconectarse de una base de datos en una rutina de salida.


v “Desconexión de aplicaciones de SQL incorporado” en la página 195


v “API de DB2” en Consulta de las API administrativas

Consideraciones sobre el manejador de excepciones, señales

e interrupciones

Un manejador de excepciones, señales o interrupciones es una rutina que adquiere

el control cuando se produce una excepción, señal o interrupción. El tipo de

manejador aplicable lo determina el entorno operativo, tal como se muestra a

continuación:

Sistemas operativos Windows

Al pulsar Control-C o Control-Inter se genera una interrupción.

Sistemas operativos UNIX

Generalmente, al pulsar Control-C se genera una señal de interrupción

SIGINT. Observe que los teclados se pueden redefinir fácilmente de modo

que se pueda generar una señal SIGINT pulsando otra secuencia de teclas

en la máquina.

No coloque sentencias de SQL (que no sean COMMIT o ROLLBACK) en

manejadores de excepciones, señales e interrupciones. Con estos tipos de

condiciones de error, generalmente deseará llevar a cabo una operación

ROLLBACK para evitar el riesgo de tener datos incoherentes.

Tenga en cuenta que debe tener cuidado cuando codifique COMMIT y ROLLBACK

en manejadores de excepciones/señales/interrupciones. Si llama a cualquiera de

estas sentencias por ellas mismas, la operación COMMIT o ROLLBACK no se

ejecuta hasta que se completa la sentencia de SQL actual, si se está ejecutando

alguna. Este no es el comportamiento deseado de un manejador Control-C.

La solución consiste en llamar a la API INTERRUPT (sqleintr/sqlgintr) antes de

emitir una operación ROLLBACK. Esta API interrumpe la consulta de SQL actual

(si la aplicación está ejecutando alguna) y deja que ROLLBACK comience de

inmediato. Si va a realizar una operación COMMIT en lugar de ROLLBACK, no

desea interrumpir el mandato actual.

Cuando se utiliza APPC para acceder a un servidor de bases de datos remoto (DB2

para AIX o el sistema de bases de datos de sistema principal que utiliza DB2

Connect), es posible que la aplicación reciba una señal SIGUSR1. SNA

Services/6000 genera esta señal cuando se produce un error no recuperable y la

conexión SNA se detiene. Es posible que desee instalar un manejador de señales en

la aplicación para que maneje SIGUSR1.

Consulte la documentación de su plataforma para ver detalles específicos sobre

consideraciones sobre distintos manejadores.



v “Manejo de errores utilizando la sentencia WHENEVER” en la página 57


página 191





v “Sentencia COMMIT” en Consulta de SQL, Volumen 2

v “Sentencia ROLLBACK” en Consulta de SQL, Volumen 2

Desconexión de aplicaciones de SQL incorporado

La sentencia disconnect es el último paso cuando se trabaja con una base de datos.

Este tema contiene ejemplos de la sentencia disconnect en los lenguajes principales

soportados.

Desconexión de bases de datos DB2 en aplicaciones de SQL incorporado C y

C++:

Cuando se trabaja con aplicaciones C y C++, una conexión de base de datos se

cierra emitiendo la siguiente sentencia:

EXEC SQL CONNECT RESET;

Desconexión de bases de datos DB2 en aplicaciones de SQL incorporado

COBOL:

Cuando se trabaja con aplicaciones COBOL, una conexión de base de datos se


EXEC SQL CONNECT RESET END-EXEC.

Desconexión de bases de datos DB2 en aplicaciones de SQL incorporado REXX:

Cuando se trabaja con aplicaciones REXX, una conexión de base de datos se cierra

emitiendo la siguiente sentencia:

CALL SQLEXEC ’CONNECT RESET’

Cuando se trabaja con aplicaciones FORTRAN, una conexión de base de datos se


EXEC SQL CONNECT RESET




página 150


v “Sentencia DISCONNECT” en Consulta de SQL, Volumen 2


Capítulo 4. Creación de aplicaciones de SQL incorporado

Creación de aplicaciones de SQL incorporado . . 198


incorporado con el mandato PRECOMPILE (o

PREP) . . . . . . . . . . . . . . . . 201


incorporado con el mandato PRECOMPILE . . 201


incorporado que acceden a más de un servidor

de bases de datos . . . . . . . . . . . 203

Paquetes de aplicaciones y planes de acceso de

SQL incorporado . . . . . . . . . . . 204

Calificación de esquema de paquete utilizando

el registro especial CURRENT PACKAGE PATH . 204

Indicaciones horarias generadas por el

precompilador . . . . . . . . . . . . 208

Errores y avisos procedentes de la

precompilación aplicaciones de SQL

incorporado . . . . . . . . . . . . . 209

Compilación y enlace de archivos fuente que

contienen SQL incorporado . . . . . . . . . 209

Vinculación de paquetes de SQL incorporado con

una base de datos mediante el mandato BIND . . 210

Vinculación de paquetes de SQL incorporado

con una base de datos . . . . . . . . . 210

Efecto de la opción de vinculación

DYNAMICRULES en SQL dinámico . . . . . 211

Utilización de registros especiales para controlar

el entorno de compilación de sentencias . . . 214

Cómo volver a crear paquetes utilizando el

mandato BIND y un archivo de vinculación

existente . . . . . . . . . . . . . . 214

Revinculación de paquetes existentes con el

mandato REBIND . . . . . . . . . . . 215

Consideraciones sobre la vinculación . . . . 216

Ventajas de la vinculación diferida . . . . . 217

Mejoras en el rendimiento cuando se utiliza la

opción REOPT del mandato BIND . . . . . 218

Almacenamiento y mantenimiento de paquetes . . 219

Almacenamiento y mantenimiento de paquetes 219

Creación de versiones de paquetes . . . . . 219

Resolución de nombres de tabla no calificados 220


mediante el script de creación de ejemplo . . . . 221


mediante el script de creación de ejemplo . . . 221

Programas de utilidad de comprobación de

errores . . . . . . . . . . . . . . . 223

Creación de aplicaciones y rutinas escritas en C

y C++ . . . . . . . . . . . . . . . 225


C y C++ . . . . . . . . . . . . . 225

Creación de aplicaciones en C o C++

mediante el script de creación de ejemplo

(UNIX) . . . . . . . . . . . . . 225

Creación de aplicaciones C/C++ en Windows 227


escritas en VisualAge C++ con archivos de

configuración . . . . . . . . . . . 229


y de API de DB2 en C o C++ con archivos de

configuración (AIX) . . . . . . . . . 230

Creación de aplicaciones C/C++ de conexión

múltiple en Windows . . . . . . . . . 232

Opciones de compilación y enlace de

aplicaciones de API de DB2 y de SQL

incorporado de C de AIX . . . . . . . 234

Opciones de compilación y enlace de

aplicaciones de la API de administración de

DB2 y de SQL incorporado en C++ de AIX . 235

Opciones de compilación y enlace para

aplicaciones C de HP-UX . . . . . . . 236


aplicaciones C++ de HP-UX . . . . . . 238


aplicaciones C de Linux . . . . . . . . 239


aplicaciones C++ de Linux . . . . . . . 241


aplicaciones C de Solaris . . . . . . . 242


aplicaciones C++ de Solaris . . . . . . . 244


aplicaciones C y C++ de Windows . . . . 245


COBOL . . . . . . . . . . . . . . 246


COBOL . . . . . . . . . . . . . 246

Creación de aplicaciones IBM COBOL en AIX 246

Creación de aplicaciones Micro Focus

COBOL de UNIX . . . . . . . . . . 248

Creación de aplicaciones IBM COBOL en

Windows . . . . . . . . . . . . . 249

Creación de aplicaciones Micro Focus

COBOL en Windows . . . . . . . . . 251

Configuración del compilador IBM COBOL

en Windows . . . . . . . . . . . . 253

Configuración del compilador Micro Focus

COBOL en Windows . . . . . . . . . 254


COBOL en Linux . . . . . . . . . . 255

Configuración del compilador IBM COBOL

en AIX . . . . . . . . . . . . . 256


COBOL en AIX . . . . . . . . . . . 257


COBOL en HP-UX . . . . . . . . . . 258


COBOL en Solaris . . . . . . . . . . 258


aplicaciones IBM COBOL de AIX . . . . . 259



aplicaciones Micro Focus COBOL de AIX . . 260


aplicaciones Micro Focus COBOL de HP-UX . 261


aplicaciones Micro Focus COBOL de Solaris . 261


aplicaciones Micro Focus COBOL de Linux . 262


aplicaciones IBM COBOL de Windows . . . 263


aplicaciones Micro Focus COBOL de

Windows . . . . . . . . . . . . . 264


incorporado escritas en REXX . . . . . . . 265


incorporado escritas en REXX . . . . . . 265

Archivos de vinculación de REXX . . . . 266

Creación de aplicaciones Object REXX en

Windows . . . . . . . . . . . . . 267


desde la línea de mandatos . . . . . . . . . 268


desde la línea de mandatos . . . . . . . . 268


escritas en C o C++ (Windows) . . . . . . 268

Migración de las aplicaciones de SQL incorporado 269

Restricciones de enlazar a libdb2.so . . . . . . 271


Cuando haya creado el código fuente para la aplicación de SQL incorporado, debe

seguir otros pasos para construirla. Deberá considerar construir ejecutables de 64

bits al desarrollar nuevas aplicaciones de bases de datos de SQL incorporado.

Además de compilar y enlazar el programa, debe precompilarlo y vincularlo.

El proceso de precompilación convierte sentencias de SQL incorporado en llamadas

a API de tiempo de ejecución de DB2 que un compilador del lenguaje principal

pueda procesar. Por omisión, se crea un paquete en el momento de la

precompilación. Opcionalmente, se puede crear un archivo de vinculación en el

momento de la precompilación. El archivo de vinculación contiene información

sobre las sentencias de SQL del programa de aplicación. El archivo de vinculación

se puede utilizar más adelante con el mandato BIND para crear un paquete para la

aplicación.

La vinculación es el proceso de crear un paquete a partir de un archivo de

vinculación y de almacenarlo en una base de datos. El archivo de vinculación se

debe vincular a cada base de datos a la que tenga que acceder la aplicación. Si la

aplicación accede a más de una base de datos, debe crear un paquete para cada

base de datos.

Para ejecutar aplicaciones escritas en lenguajes principales compilados, debe crear

los paquetes que necesita el gestor de bases de datos en el momento de la

ejecución. La figura siguiente muestra el orden de estos pasos, junto con los

distintos módulos de una típica aplicación de DB2 compilada:

1. Cree archivos fuente que contengan programas con sentencias de SQL

incorporado.

2. Conecte con una base de datos y luego precompile cada archivo fuente para

convertir las sentencias fuente de SQL incorporado en un formato que el gestor

de bases de datos pueda utilizar

Puesto que las sentencias de SQL colocadas en una aplicación no son

específicas del lenguaje principal, el gestor de bases de datos proporciona una

forma de convertir la sintaxis de SQL para que la procese el lenguaje principal.

Para los lenguajes C, C++, COBOL o FORTRAN, esta conversión se maneja

mediante el precompilador de DB2 que se invoca mediante el mandato

PRECOMPILE (o PREP). El precompilador convierte las sentencias de SQL

incorporado directamente en llamadas a API de servicios de tiempo de

ejecución de DB2. Cuando el precompilador procesa un archivo fuente, busca

específicamente sentencias de SQL y evita el lenguaje principal que no es SQL.


3. Compile los archivos fuente modificados (y otros archivos sin sentencias de

SQL) mediante el compilador del lenguaje principal.

4. Enlace los archivos de objeto con las bibliotecas de DB2 y del lenguaje principal

para generar un programa ejecutable.

Compilación y enlace (pasos 3 y 4), para crear los módulos de objeto necesarios

5. Vincule el archivo de vinculación para crear el paquete si esto no se ha hecho

en el momento de la precompilación o si se va a acceder a una base de datos

distinta. La vinculación crea el paquete que utilizará el gestor de bases de datos

cuando se ejecute el programa.

6. Ejecute la aplicación. La aplicación accede a la base de datos utilizando los

planes de acceso.

Capítulo 4. Creación de aplicaciones de SQL incorporado 199



página 74




página 210

v “Paquetes de aplicaciones y planes de acceso de SQL incorporado” en la página

204


Figura 4. Preparación de programas escritos en lenguajes principal compilados



v “Compilación y enlace de archivos fuente que contienen SQL incorporado” en la

página 209


v “Mandato BIND” en Consulta de mandatos


Precompilación de aplicaciones de SQL incorporado con el mandato

PRECOMPILE (o PREP)

Precompilación de aplicaciones de SQL incorporado con el

mandato PRECOMPILE

Cuando haya creado los archivos fuente de la aplicación de SQL incorporado, debe

precompilar cada archivo del lenguaje principal que contenga sentencias de SQL

con el mandato PREP, utilizando las opciones específicas del lenguaje principal. El

precompilador convierte las sentencias de SQL contenidas en el archivo fuente en

comentarios y genera las llamadas a API en tiempo de ejecución de DB2 para

dichas sentencias.

Siempre debe precompilar un archivo fuente contra una base de datos específica,

incluso si finalmente no utiliza la base de datos con la aplicación. En la práctica,

puede utilizar una base de datos de prueba para desarrollo y, después de probar

por completo la aplicación, puede vincular su archivo de vinculación a una o más

bases de datos de producción. Esta práctica recibe el nombre de vinculación diferida.

Si la aplicación utiliza una página de códigos distinta de la página de códigos de la

base de datos, debe tener en cuenta qué página de códigos debe utilizar al

precompilar.

Si la aplicación utiliza funciones definidas por el usuario (UDF) o tipos

diferenciados definidos por el usuario (UDT), es posible que tenga que utilizar la

opción FUNCPATH al precompilar la aplicación. Esta opción especifica la vía de

acceso de función que se utiliza para resolver las UDF y UDT para aplicaciones

que contienen SQL estático. Si no se especifica FUNCPATH, la vía de acceso de

función por omisión es SYSIBM, SYSFUN, USER, donde USER hace referencia al

ID de usuario actual.

Antes de precompilar una aplicación, debe conectarse con el servidor, de forma

implícita o explícita. Aunque precompile programas de aplicación en la estación de

trabajo cliente y el precompilador genere fuente modificada y mensajes en el

cliente, el precompilador utiliza la conexión con el servidor para llevar a cabo parte

de la validación.

El precompilador también crea la información que necesita el gestor de bases de

datos para procesar las sentencias de SQL contra una base de datos. Esta

información se almacena en un paquete, en un archivo de vinculación o en ambos,

en función de las opciones del precompilador seleccionadas.

A continuación se muestra un ejemplo típico de cómo utilizar el precompilador.

Para precompilar un archivo fuente de SQL incorporado C denominado


filename.sqc, puede emitir el siguiente mandato para crear un archivo fuente C con

el nombre por omisión filename.c y un archivo de vinculación con el nombre por

omisión filename.bnd:

DB2 PREP filename.sqc BINDFILE

El precompilador genera un máximo de cuatro tipos de salida:

Fuente modificada

Este archivo es la nueva versión del archivo fuente original

después de que el precompilador convierta las sentencias de SQL

en llamadas a API en tiempo de ejecución de DB2. Se le asigna la

extensión adecuada para el lenguaje principal.

Paquete Si utiliza la opción PACKAGE (el valor por omisión) o si no

especifica ninguna de las opciones BINDFILE, SYNTAX o

SQLFLAG, el paquete se almacena en la base de datos conectada.

El paquete contiene toda la información necesaria para ejecutar las

sentencias de SQL estático de un archivo fuente particular contra

esta base de datos únicamente. A no ser que especifique otro

nombre con la opción PACKAGE USING, el precompilador forma

el nombre del paquete a partir de los 8 primeros caracteres del

nombre del archivo fuente.

Si utiliza la opción PACKAGE sin SQLERROR CONTINUE, la base

de datos que se utiliza durante el proceso de precompilación debe

contener todos los objetos de base de datos a los que hacen

referencia las sentencias de SQL estático en el archivo fuente. Por

ejemplo, no puede precompilar una sentencia SELECT a no ser que

la tabla a la que hace referencia exista en la base de datos.

Con la opción VERSION, el archivo de vinculación (si se utiliza la

opción BINDFILE) y el paquete (tanto si se vincula en el momento

de PREP como si se vincula por separado) se designarán con un

identificador de versión particular. Pueden existir simultáneamente

muchas versiones de paquetes con el mismo nombre y creador.

Archivo de vinculación

Si utiliza la opción BINDFILE, el precompilador crea un archivo de

vinculación (con la extensión .bnd) que contiene los datos

necesarios para crear un paquete. Este archivo se puede utilizar

más adelante con el mandato BIND para vincular la aplicación a

una o más bases de datos. Si especifica BINDFILE y no especifica

la opción PACKAGE, la vinculación se difiere hasta que invoca el

mandato BIND. Observe que para el procesador de línea de

mandatos (CLP), el valor por omisión para PREP no especifica la

opción BINDFILE. Por lo tanto, si utiliza el CLP y desea que la

vinculación se difiera, tiene que especificar la opción BINDFILE.

Si se especifica SQLERROR CONTINUE se crea un paquete,

aunque se produzcan errores al vincular sentencias de SQL. Estas

sentencias que no se pueden vincular por motivos de autorización

o de existencia se pueden vincular de forma incremental en el

momento de la ejecución si también se especifica VALIDATE RUN.

Si se intenta ejecutarlas en el momento de la ejecución se genera

un error.

Archivo de mensajes

Si utiliza la opción MESSAGES, el precompilador redirige los

mensajes al archivo indicado. Estos mensajes incluyen avisos y


mensajes de error que describen problemas encontrados durante la

precompilación. Si el archivo fuente no se precompila

satisfactoriamente, utilice los mensajes de aviso y de error para

determinar el problema, corrija el archivo fuente y luego vuelva a

intentar precompilar el archivo fuente. Si no utiliza la opción

MESSAGES, los mensajes de precompilación se graban en la salida

estándar.


v “Ventajas de la vinculación diferida” en la página 217



v “Substituciones de caracteres durante conversiones de páginas de códigos” en


v “Factor de expansión de conversión de páginas de códigos” en Desarrollo de SQL

y rutinas externas

v “Conversiones de páginas de códigos soportadas” en Desarrollo de SQL y rutinas

externas

v “Cuándo se produce la conversión de página de códigos” en Desarrollo de SQL y

rutinas externas


página 74



página 210


página 58









Precompilación de aplicaciones de SQL incorporado que

acceden a más de un servidor de bases de datos

Para precompilar un programa de aplicación que accede a más de un servidor,

puede hacer una de las siguientes cosas:

v Dividir las sentencias de SQL correspondientes a cada base de datos en archivos

fuente separados. No combine sentencias de SQL correspondientes a distintas

bases de datos en el mismo archivo. Cada archivo fuente se puede precompilar

contra la base de datos apropiada. Este es el método recomendado.

v Codificar la aplicación utilizando únicamente sentencias de SQL dinámico y

vincular contra cada base de datos a la que va a acceder el programa.

v Si todas las bases de datos se parecen, es decir, tienen la misma definición,

puede agrupar las sentencias de SQL en un archivo fuente.


Los mismos procedimientos se aplican si la aplicación va a acceder a un servidor

de aplicaciones a través de DB2 Connect. Precompílela contra el servidor al que se

va a conectar, utilizando las opciones de PREP disponibles para dicho servidor.





página 58

Paquetes de aplicaciones y planes de acceso de SQL

incorporado

El precompilador genera un paquete en la base de datos y, opcionalmente, un

archivo de vinculación, si especifica que desea que se cree uno.

El paquete contiene planes de acceso seleccionados por el optimizador de DB2

para las sentencias de SQL estático de la aplicación. Los planes de acceso contienen

la información que necesita el gestor de bases de datos para ejecutar las sentencias

de SQL estático de la forma más eficiente, según determine el optimizador. Para

sentencias de SQL dinámico, el optimizador crea planes de acceso cuando el

usuario ejecuta la aplicación.

Los paquetes almacenados en la base de datos incluyen la información necesaria

para ejecutar sentencias de SQL específicas en un solo archivo fuente. Una

aplicación de base de datos utiliza un paquete para cada archivo fuente

precompilado utilizado para crear la aplicación. Cada paquete constituye una

entidad separada y no tiene ninguna relación con ningún otro paquete utilizado

por la misma o por otras aplicaciones. Los paquetes se crean ejecutando el

precompilador contra un archivo fuente con la vinculación habilitada o ejecutando

el vinculador posteriormente con uno o más archivos de vinculación.

El archivo de vinculación contiene las sentencias de SQL y otros datos necesarios

para crear un paquete. Puede utilizar el archivo de vinculación para revincular la

aplicación más adelante sin tener que precompilarla primero. La revinculación crea

paquetes optimizados para las condiciones actuales de la base de datos. Tiene que

revincular la aplicación si va a acceder a una base de datos distinta de aquella

contra la cual se precompiló.




página 210


215

Calificación de esquema de paquete utilizando el registro

especial CURRENT PACKAGE PATH

Los esquemas de paquete proporcionan un método para la agrupación lógica de

paquetes. Existen diferentes métodos para agrupar paquetes y formar esquemas.

Algunas implementaciones utilizan un esquema por cada entorno (por ejemplo, un

esquema de producción y un esquema de prueba). Otras implementaciones utilizan


un esquema por área de negocio (por ejemplo, los esquemas stocktrd y onlinebnk)

o un esquema por aplicación (por ejemplo, stocktrdAddUser y onlinebnkAddUser).

También puede agrupar paquetes con finalidades de administración general o para

proporcionar variaciones en los paquetes (por ejemplo, mantener variaciones de

copia de seguridad de aplicaciones o probar variaciones nuevas de aplicaciones).

Cuando se utilizan varios esquemas para los paquetes, el gestor de la base de

datos debe determinar el esquema en el que ha de buscarse un paquete. Para

realizar esta tarea, el gestor de bases de datos utiliza el valor del registro especial

CURRENT PACKAGESET. Puede definir este registro especial para un solo nombre

de esquema para indicar que cualquier paquete a invocar pertenece a ese esquema.

Si una aplicación utiliza paquetes en esquemas diferentes, es posible que tenga que

emitirse una sentencia SET CURRENT PACKAGESET antes de que se invoque

cualquier paquete en el caso de que el esquema para el paquete sea diferente

respecto del paquete anterior.

Nota: Únicamente DB2 Versión 9.1 para z/OS (DB2 para z/OS) tiene un registro

especial de CURRENT PACKAGESET, que le permitirá definir

explícitamente el valor (un único nombre de esquema) con la sentencia SET

CURRENT PACKAGESET correspondiente. Aunque DB2 Database para

Linux, UNIX y Windows tiene una sentencia SET CURRENT PACKAGESET,

no tiene un registro especial CURRENT PACKAGESET. Esto significa que no

se puede hacer referencia a CURRENT PACKAGESET en otros contextos

(por ejemplo en una sentencia (por ejemplo en una sentencia SELECT) con

DB2 Database para Linux, UNIX y Windows. DB2 UDB para iSeries no

proporciona soporte para CURRENT PACKAGESET.

El servidor de bases de datos de DB2 tiene más flexibilidad cuando puede tomar

en consideración una lista de esquemas durante la resolución de paquetes. La lista

de esquemas es similar a la vía de acceso a SQL que se proporciona por medio del

registro especial CURRENT PATH. La lista de esquemas se utiliza para las

funciones definidas por el usuario, procedimientos, métodos y tipos diferenciados.

Nota: La vía de acceso a SQL es una lista de nombres de esquema que DB2

debería tener en cuenta al intentar determinar el esquema para un nombre

de tipo diferenciado, método, procedimiento o función no calificada.

Si necesita asociar múltiples variaciones de un paquete (es decir, múltiples

conjuntos de opciones BIND de un paquete) con un único programa compilado,

considere la posibilidad de aislar la vía de acceso de los esquemas que se utilizan

para objetos de SQL respecto de la vía de acceso de los esquemas que se utilizan

para paquetes.

El registro especial CURRENT PACKAGE PATH le permite especificar una lista de

esquemas de paquete. Otros productos de la familia DB2 proporcionan una

capacidad similar con registros especiales tales como CURRENT PATH y

CURRENT PACKAGESET, que se utilizan para procedimientos anidados y

funciones definidas por el usuario, sin corromper el entorno de ejecución de la

aplicación invocante. El registro especial CURRENT PACKAGE PATH proporciona

esta capacidad para la resolución de esquemas del paquete.

Muchas instalaciones utilizan más de un esquema para los paquetes. Si no

especifica una lista de esquemas de paquete, deberá emitir la sentencia SET

CURRENT PACKAGESET (que puede contener como máximo un nombre de

esquema) cada vez que necesite un paquete de un esquema diferente. Sin embargo,

si emite una sentencia SET CURRENT PACKAGE PATH al principio de la


aplicación para especificar una lista de nombres de esquema, no necesita emitir

una sentencia SET CURRENT PACKAGESET cada vez que se necesite un paquete

en un esquema diferente.

Por ejemplo, suponga que existen los paquetes siguientes y, utilizando la lista

siguiente, que desea invocar el primero que existe en el servidor: SCHEMA1.PKG1,

SCHEMA2.PKG2, SCHEMA3.PKG3, SCHEMA4.PKG y SCHEMA5.PKG5.

Suponiendo que el soporte actual para una sentencia SET CURRENT

PACKAGESET de DB2 Database para Linux, UNIX y Windows (es decir, aceptando

un único nombre de esquema), tendría que emitirse una sentencia SET CURRENT

PACKAGESET antes de intentar invocar cada paquete para especificar el esquema

específico. Para este ejemplo, se tendría que emitir cinco sentencias SET CURRENT

PACKAGESET. Sin embargo, es suficiente la utilización del registro especial

CURRENT PACKAGE PATH, una única sentencia SET. Por ejemplo:

SET CURRENT PACKAGE PATH = SCHEMA1, SCHEMA2, SCHEMA3, SCHEMA, SCHEMA5;

Nota: En DB2 Database para Linux, UNIX y Windows, podrá definir el registro

especial CURRENT PACKAGE PATH en el archivo db2cli.ini, utilizando la

API de SQLSetConnectAttr, en la estructura de SQLE-CLIENT-INFO e

incluyendo la sentencia SET CURRENT PACKAGE PATH en programas SQL

intercalados. Solo DB2 Universal Database para OS/390 y z/OS, Versión 8 o

posterior, da soporte a la sentencia SET CURRENT PACKAGE PATH. Si

emite esta sentencia frente a un servidor de DB2 Database para Linux, UNIX

y Windows o frente a DB2 Universal Database para AS/00, se devuelve

-30005.

Puede utilizar múltiples esquemas para mantener diversas variaciones de un

paquete. Estas variaciones pueden ser muy útiles para ayudar a controlar los

cambios efectuados en entornos de producción. También puede utilizar diferentes

variaciones de un paquete para conservar una versión de copia de seguridad de un

paquete, o una versión de prueba de un paquete (por ejemplo, para evaluar el

impacto de un índice nuevo). También se puede utilizar una versión anterior de un

paquete como una aplicación de copia de seguridad (módulo de carga o

ejecutable), concretamente, para proporcionar la posibilidad de volver a una

versión anterior.

Por ejemplo, suponga que el esquema PROD incluye los paquetes actuales

utilizados por las aplicaciones de producción, y que el esquema BACKUP guarda

una copia de seguridad de esos paquetes. Una versión nueva de la aplicación (y

por tanto de los paquetes) se promociona a la versión de producción mediante la

vinculación por medio del esquema PROD. Las copias de seguridad de los

paquetes se crean vinculando la versión actual de las aplicaciones mediante el

esquema de copia de seguridad (BACKUP). Después, durante la ejecución, puede

utilizar la sentencia SET CURRENT PACKAGE PATH para especificar el orden en

el que se deben examinar los esquemas para los paquetes. Suponga que se ha

vinculado una copia de seguridad de la aplicación MYAPPL utilizando el esquema

BACKUP y que la versión de la aplicación que está actualmente en producción se

ha vinculado al esquema PROD creando un paquete PROD.MYAPPL. Para

especificar que debe utilizarse la variación del paquete contenida en el esquema

PROD si está disponible (de lo contrario se utilizará la variación contenida en el

esquema BACKUP), emita la sentencia SET siguiente para el registro especial:

SET CURRENT PACKAGE PATH = PROD, BACKUP;

Si necesita volver a la versión anterior del paquete, la versión de producción de la

aplicación puede descartarse con la sentencia DROP PACKAGE, que hace que se

invoque la versión anterior de la aplicación (módulo de carga o ejecutable) que se


vinculó utilizando el esquema BACKUP (aquí se pueden utilizar técnicas de vía de

acceso de aplicación, específicas de cada plataforma de sistema operativo).

Nota: Este ejemplo asume que la única diferencia entre las versiones del paquete

están en las opciones BIND que se utilizaron para crear los paquetes (es

decir, no hay diferencias en el código ejecutable).

La aplicación no utiliza la sentencia SET CURRENT PACKAGESET para

seleccionar el esquema que desea. En su lugar, permite a DB2 seleccionar el

paquete buscándolo en los esquemas listados en el registro especial CURRENT

PACKAGE PATH.

Nota: El proceso de precompilación de DB2 Universal Database para OS/390 y

z/OS almacena una señal de coherencia en el DBRM (que puede definirse

utilizando la opción LEVEL) y durante la resolución de paquetes, se efectúa

una comprobación para asegurarse de que la señal de coherencia del

programa corresponde al paquete. De modo análogo, el proceso de

vinculación de DB2 Database para Linux, UNIX y Windows almacena una

indicación horaria en el proceso de vinculación. DB2 Database para Linux,

UNIX y Windows también da soporte a una opción LEVEL.

Otro motivo para crear varias versiones de un paquete en esquemas diferentes

podría ser el de hacer que entren en vigor diferentes opciones de BIND. Por

ejemplo, pueden utilizarse calificadores diferentes para referencias de nombre sin

calificar en el paquete.

Las aplicaciones se escriben a menudo con nombres de tabla sin calificar. Esta

acción da soporte a múltiples tablas que tienen estructuras y nombres de tabla

idénticos, pero calificadores diferentes para distinguir instancias diferentes. Por

ejemplo, se pueden haber creado los mismos objetos en un sistema de prueba y en

un sistema de producción, pero esos objetos pueden tener calificadores diferentes

(por ejemplo, PROD y TEST). Otro ejemplo es una aplicación que distribuya datos

en tablas de diferentes sistemas DB2, en los que cada tabla tenga un calificador

diferente (por ejemplo, EAST, WEST, NORTH, SOUTH; COMPANYA,

COMPANYB; Y1999, Y2000, Y2001). En DB2 Universal Database para OS/390 y

z/OS, especifique el calificador de tabla utilizando la opción QUALIFIER del

mandato BIND. Cuando se utilice la opción QUALIFIER, los usuarios no tendrán

que mantener múltiples programas, cada uno de ellos especificará los nombres

totalmente calificados que se necesiten para acceder a las tablas sin calificar. En vez

de eso, puede accederse al paquete correcto en tiempo de ejecución emitiendo la

sentencia SET CURRENT PACKAGESET desde la aplicación y especificando un

único nombre de esquema. Sin embargo, si utiliza SET CURRENT PACKAGESET,

seguirá siendo necesario conservar y modificar múltiples aplicaciones: cada una de

ellas con su propia sentencia SET CURRENT PACKAGESET para acceder al

paquete necesario. Si en vez de eso se emite una sentencia SET CURRENT

PACKAGE PATH, se podría listar la totalidad de los esquemas. En el momento de

la ejecución, DB2 podría seleccionar el paquete correcto.

Nota: DB2 Database para Linux, UNIX y Windows también da soporte a una

opción de vinculación QUALIFIER. Sin embargo, la opción de vinculación

QUALIFIER sólo afecta al SQL estático o a los paquetes que utilizan la

opción DYNAMICRULES del mandato BIND.


v “Sentencia SET CURRENT PACKAGESET” en Consulta de SQL, Volumen 2


v “Registro especial CURRENT PATH” en Consulta de SQL, Volumen 1

Indicaciones horarias generadas por el precompilador

Cuando una aplicación se precompila con la vinculación habilitada, el paquete y el

archivo fuente modificado se generan con indicaciones horarias que coinciden.

Estas indicaciones horarias se conocen de forma individual como una señal de

coherencia. Si existen varias versiones de un paquete (utilizando la opción

PRECOMPILE VERSION), cada versión tendrá una indicación horaria asociada.

Cuando se ejecuta una aplicación, el nombre del paquete, el creador y la indicación

horaria se envían al gestor de bases de datos, el cual comprueba si hay algún

paquete cuyo nombre, creador e indicación horaria coinciden con los enviados por

la aplicación. Si no existe dicha coincidencia, se devuelve uno de los siguientes

códigos de error de SQL a la aplicación:

v SQL0818N (conflicto de indicaciones horarias). Este error se devuelve si se

encuentra un solo paquete que coincide con el nombre y creador (pero no con la

señal de coherencia) y el paquete tiene la versión ″″ (una serie vacía)

v SQL0805N (paquete no encontrado). Este error se devuelve en las demás

situaciones.

Recuerde que cuando vincula una aplicación a una base de datos, los ocho

primeros caracteres del nombre de la aplicación se utilizan como el nombre del

paquete a no ser que altere temporalmente el valor por omisión utilizando la opción

PACKAGE USING en el mandato PREP. Asimismo, el ID de versión será ″″ (una

serie vacía), a no ser que se especifique mediante la opción VERSION del mandato

PREP. Esto significa que si precompila y vincula dos programas utilizando el

mismo nombre sin cambiar el ID de versión, el segundo paquete sustituirá al

paquete del primero. Cuando ejecute el primer programa, obtendrá un error de

indicación horaria o de paquete no encontrado porque la indicación horaria

correspondiente al archivo fuente modificado ya no coincide con la del paquete en

la base de datos. El error de paquete no encontrado puede proceder del uso de la

opción de precompilación o de vinculación ACTION REPLACE REPLVER, como

en el siguiente ejemplo:

1. Precompile y vincule el paquete SCHEMA1.PKG especificando VERSION

VER1. Luego genere la aplicación asociada A1.

2. Precompile y vincule el paquete SCHEMA1.PKG, especificando VERSION

VER2 ACTION REPLACE REPLVER VER1. Luego genere la aplicación asociada

A2.

La segunda precompilación y vinculación genera un paquete SCHEMA1.PKG

que tiene para VERSION el valor VER2 y la especificación de ACTION

REPLACE REPLVER VER1 elimina el paquete SCHEMA1.PKG que tenía para

VERSION el valor VER1.

Si se intenta ejecutar la primera aplicación, se producirá una falta de

coincidencia de paquetes y el intento fallará.

Un síntoma parecido sucedería en el siguiente ejemplo:





En este momento es posible ejecutar ambas aplicaciones, A1 y A2, que se

ejecutarían desde los paquetes SCHEMA1.PKG con versiones VER1 y VER2

respectivamente. Si, por ejemplo, se elimina el primer paquete (utilizando la


sentencia DROP PACKAGE SCHEMA1.PKG VERSION VER1 SQL), el intento

de ejecutar la aplicación A1 fallaría con un error de paquete no encontrado.

Cuando un archivo fuente se precompila pero no se crea un paquete, se genera un

archivo de vinculación y un archivo fuente modificado con indicaciones horarias

coincidentes. Para ejecutar la aplicación, el archivo de vinculación se vincula en un

paso BIND independiente para crear un paquete y el archivo fuente modificado se

compila y se enlaza. Para una aplicación que necesita varios módulos fuente, el

proceso de vinculación se debe realizar para cada archivo de vinculación.

En este escenario de vinculación diferida, las indicaciones horarias de la aplicación

y del paquete coinciden porque el archivo de vinculación contiene la misma

indicación horaria que el que se almacenó en el archivo fuente modificado durante

la precompilación.


v “Cómo volver a crear paquetes utilizando el mandato BIND y un archivo de

vinculación existente” en la página 214


204


página 210

v “Creación de versiones de paquetes” en la página 219

Errores y avisos procedentes de la precompilación


El precompilador de SQL incorporado detecta los errores de SQL incorporado en el

momento de la precompilación. El precompilador de SQL incorporado detecta los

errores de sintaxis, por ejemplo la falta de signos de punto y coma y las variables

del lenguaje principal no declaradas en sentencias de SQL. Para cada uno de estos

errores, se genera un mensaje de error adecuado.


v “Programación de aplicaciones de SQL incorporado” en la página 42

Compilación y enlace de archivos fuente que contienen SQL

incorporado

Cuando se precompilan archivos fuente de SQL incorporado, el mandato

PRECOMPILE genera archivos fuente modificados con una extensión de archivo que

se puede aplicar al lenguaje de programación.

Compile los archivos fuente modificados (y los archivos fuente adicionales que no

contienen sentencias de SQL) utilizando el compilador de lenguaje principal

adecuado. El compilador de lenguaje convierte cada archivo fuente modificado en

un módulo de objeto.

Consulte la documentación sobre programación correspondiente a su plataforma

operativa para ver las excepciones a las opciones del compilador por omisión.

Consulte la documentación del compilador para ver una descripción completa de

las opciones disponibles del compilador.


El enlazador del lenguaje principal crea una aplicación ejecutable. Por ejemplo:

v En sistemas operativos Windows, la aplicación puede ser un archivo ejecutable o

una biblioteca de enlace dinámico (DLL).

v En sistemas operativos basados en UNIX y Linux, la aplicación puede ser un

módulo de carga ejecutable o una biblioteca compartida.

Nota: Aunque las aplicaciones pueden ser bibliotecas de enlace dinámico (DLL) en

los sistemas operativos Windows, las DLL son cargadas directamente por la

aplicación y no por el gestor de bases de datos de DB2. En sistemas

operativos Windows, el gestor de bases de datos carga los procedimientos

almacenados de SQL incorporado y las funciones definidas por el usuario

como DLL.

Para crear el archivo ejecutable, enlace lo siguiente:

v Módulos de objetos de usuario, generados por el compilador del lenguaje a

partir de los archivos fuente modificados y otros archivos que no contienen

sentencias de SQL.

v API de biblioteca de lenguaje principal, que se suministran con el compilador

del lenguaje.

v La biblioteca del gestor de bases de datos que contiene las API del gestor de

bases de datos correspondientes a su entorno operativo. Consulte la

documentación sobre programación adecuada para su plataforma operativa para

ver el nombre específico de la biblioteca del gestor de bases de datos que

necesita para las API del gestor de bases de datos.


v “Creación y ejecución de aplicaciones de SQL incorporado escritas en REXX” en

la página 265

v “Creación de aplicaciones en C o C++ mediante el script de creación de ejemplo

(UNIX)” en la página 225

v “Creación de aplicaciones IBM COBOL en AIX” en la página 246

v “Creación de aplicaciones Micro Focus COBOL de UNIX” en la página 248

Vinculación de paquetes de SQL incorporado con una base de datos

mediante el mandato BIND

Vinculación de paquetes de SQL incorporado con una base de

datos

La vinculación es el proceso de crear un paquete a partir de un archivo de

vinculación y de almacenarlo en una base de datos.

Relaciones entre aplicación, archivo de vinculación y paquete:

Las aplicaciones de bases de datos utilizan paquetes por algunas de las mismas

razones por las que se compilan las aplicaciones: mejora de rendimiento y de

compactación. Al precompilar una sentencia de SQL, la sentencia se compila en el

paquete cuando se crea la aplicación en lugar de hacerlo en el tiempo de ejecución.

Cada sentencia se analiza y se almacena en el paquete una serie de operandos

interpretados de forma más eficiente. Durante la ejecución, el código que ha

generado el precompilador llama a las API del gestor de bases de datos de


servicios de tiempo de ejecución con la información sobre variables necesaria para

la entrada o salida de datos y la información almacenada en el paquete se ejecuta.

Las ventajas de la precompilación sólo se aplican a sentencias de SQL estático. Las

sentencias de SQL que se ejecutan de forma dinámica (utilizando PREPARE y

EXECUTE o EXECUTE IMMEDIATE) no se precompilan; por lo tanto, deben pasar

por todo el conjunto de pasos de proceso en el tiempo de ejecución.

Con el programa de utilidad de descripción de archivos de vinculación de DB2

(db2bfd), puede visualizar fácilmente el contenido de un archivo de vinculación

para examinar y verificar las sentencias de SQL que contiene, así como visualizar

las opciones de precompilación utilizadas para crear el archivo de vinculación. Esto

puede resultar útil en la determinación de problemas relacionados con el archivo

de vinculación de la aplicación.



v “Mejoras en el rendimiento cuando se utiliza la opción REOPT del mandato

BIND” en la página 218


v “db2bfd - Mandato Herramienta de descripción de archivo de vinculación” en

Consulta de mandatos



Efecto de la opción de vinculación DYNAMICRULES en SQL

dinámico

La opción DYNAMICRULES de los mandatos PRECOMPILE y BIND determina

los valores que se aplicarán en el momento de la ejecución para los siguientes

atributos de SQL:

v El ID de autorización que se utiliza durante la comprobación de autorización.

v El calificador que se utiliza para la calificación de objetos no calificados.

v Si el paquete se puede utilizar para preparar de forma dinámica las siguientes

sentencias: GRANT, REVOKE, ALTER, CREATE, DROP, COMMENT ON,

RENAME, SET INTEGRITY y SET EVENT MONITOR STATE.

Además del valor de DYNAMICRULES, el entorno de tiempo de ejecución de un

paquete controla el modo en que se comportan las sentencias de SQL en el

momento de la ejecución. Los dos posibles entornos de tiempo de ejecución son:

v El paquete se ejecuta formando parte de un programa autónomo

v El paquete se ejecuta dentro del contexto de una rutina

La combinación del valor de DYNAMICRULES y del entorno de tiempo de

ejecución determina los valores correspondientes a los atributos de SQL dinámico.

Este conjunto de valores de atributos se denomina comportamiento de las

sentencias de SQL dinámico. Los cuatro comportamientos son:

Comportamiento de ejecución

DB2 utiliza el ID de autorización del usuario (el ID que se conectó

inicialmente a DB2) que ejecuta el paquete como valor que se va a

utilizar para la comprobación de autorización de sentencias de SQL


dinámico y como valor inicial utilizado para la calificación

implícita de referencias a objetos no calificados dentro de

sentencias de SQL dinámico.

Comportamiento de vinculación

En el momento de la ejecución, DB2 utiliza todas las normas que

se aplican al SQL estático para la autorización y calificación. Es

decir, se toma el ID de autorización del propietario del paquete

como valor que se va a utilizar para la comprobación de

autorización de sentencias de SQL dinámico y el calificador por

omisión del paquete para la calificación implícita de referencias a

objetos no calificados dentro de sentencias de SQL dinámico.

Comportamiento de definición

El comportamiento de definición sólo se aplica si la sentencia de

SQL dinámico está en un paquete que se ejecuta dentro del

contexto de una rutina y el paquete se vinculó con

DYNAMICRULES DEFINEBIND o DYNAMICRULES

DEFINERUN. DB2 utiliza el ID de autorización del definidor de la

rutina (no el vinculador de paquetes de la rutina) como valor que

se va a utilizar para la comprobación de autorización de sentencias

de SQL dinámico y para la calificación implícita de referencias a

objetos no calificados dentro de sentencias de SQL dinámico

contenidas en dicha rutina.

Comportamiento de invocación

El comportamiento de invocación sólo se aplica si la sentencia de

SQL dinámico está en un paquete que se ejecuta dentro del

contexto de una rutina y el paquete se vinculó con

DYNAMICRULES INVOKEBIND o DYNAMICRULES

INVOKERUN. DB2 utiliza el ID de autorización de sentencias

actualmente en vigor cuando se invoca la rutina como valor que se

va a utilizar para la comprobación de autorización de SQL

dinámico y para la calificación implícita de referencias a objetos no

calificados dentro de sentencias de SQL dinámico contenidas en

dicha rutina. Esto se resume en la tabla siguiente:

Entorno de invocación ID utilizado

Cualquier SQL estático Valor implícito o explícito del propietario

(OWNER) del paquete del que procede el

SQL que invoca la rutina.

Utilizado en definición de vista o activador Definidor de la vista o del activador.

SQL dinámico procedente de un paquete de

comportamiento de ejecución

ID utilizado para efectuar la conexión inicial

con DB2.

SQL dinámico procedente del paquete de

comportamiento de definición

Definidor de la rutina que utiliza el paquete

del que procede el SQL que invoca la rutina.

SQL dinámico procedente de un paquete de

comportamiento de invocación

ID de autorización actual que invoca la

rutina.

La tabla siguiente muestra la combinación del valor de DYNAMICRULES y el

entorno de tiempo de ejecución que da lugar a cada comportamiento del SQL

dinámico.


Tabla 20. Cómo DYNAMICRULES y el entorno de tiempo de ejecución determinan el comportamiento de las

sentencias de SQL dinámico

Valor de DYNAMICRULES Comportamiento de sentencias de

SQL dinámico en un entorno de

programa autónomo

Comportamiento de sentencias de SQL

dinámico en un entorno de rutina

BIND Comportamiento de vinculación Comportamiento de vinculación

RUN Comportamiento de ejecución Comportamiento de ejecución

DEFINEBIND Comportamiento de vinculación Comportamiento de definición

DEFINERUN Comportamiento de ejecución Comportamiento de definición

INVOKEBIND Comportamiento de vinculación Comportamiento de invocación

INVOKERUN Comportamiento de ejecución Comportamiento de invocación

La tabla siguiente muestra los valores de atributos de SQL dinámico

correspondientes a cada tipo de comportamiento de SQL dinámico.

Tabla 21. Definiciones de comportamientos de sentencias de SQL dinámico

Atributo de SQL

dinámico

Valor

correspondiente a

atributos de SQL

dinámico:

comportamiento de

vinculación

Valor

correspondiente a

atributos de SQL

dinámico:

comportamiento de

ejecución

Valor correspondiente

a atributos de SQL

dinámico:

comportamiento de

definición

Valor correspondiente a

atributos de SQL

dinámico:

comportamiento de

invocación

ID de

autorización

Valor implícito o

explícito de la opción

OWNER BIND

ID de usuario que

ejecuta el paquete

Definidor de la rutina

(no el propietario del

paquete de la rutina)

ID de autorización de

sentencias actual cuando

se invoca la rutina.

Calificador por

omisión para

objetos no

calificados

Valor implícito o

explícito de la opción

QUALIFIER BIND

Registro especial

CURRENT

SCHEMA

Definidor de la rutina

(no el propietario del

paquete de la rutina)

ID de autorización de

sentencias actual cuando

se invoca la rutina.

Puede ejecutar

GRANT,

REVOKE, ALTER,

CREATE, DROP,

COMMENT ON,

RENAME, SET

INTEGRITY y

SET EVENT

MONITOR STATE

No Sí No No


v “Consideraciones de autorización para SQL dinámico” en Desarrollo de SQL y

rutinas externas

v “Autorizaciones y vinculación de rutinas que contienen SQL” en Desarrollo de







Utilización de registros especiales para controlar el entorno

de compilación de sentencias

Para sentencias preparadas de forma dinámica, los valores de varios registros

especiales determinan el entorno de compilación de sentencias:

v El registro especial CURRENT QUERY OPTIMIZATION determina qué clase de

optimización se utiliza.

v El registro especial CURRENT PATH determina la vía de acceso de función

utilizada para la resolución de UDF y UDT.

v El registro CURRENT EXPLAIN SNAPSHOT determina qué información de

instantánea de Explain se captura.

v El registro CURRENT EXPLAIN MODE determina si la información de tabla de

Explain se captura, para cualquier sentencia de SQL dinámico que se pueda

elegir. Los valores por omisión correspondientes a estos registros especiales son

los mismos que se utilizan para las opciones de vinculación relacionadas.





v “Registro especial CURRENT EXPLAIN MODE” en Consulta de SQL, Volumen 1

v “Registro especial CURRENT EXPLAIN SNAPSHOT” en Consulta de SQL,

Volumen 1

v “Registro especial CURRENT PATH” en Consulta de SQL, Volumen 1

v “Registro especial CURRENT QUERY OPTIMIZATION” en Consulta de SQL,

Volumen 1

Cómo volver a crear paquetes utilizando el mandato BIND y

un archivo de vinculación existente

La vinculación es el proceso que crea el paquete que necesita el gestor de bases de

datos para poder acceder a la base de datos cuando se ejecuta la aplicación. Por

omisión, el mandato PRECOMPILE crea un paquete. La vinculación se realiza de

forma implícita en el momento de la precompilación, a no ser que se especifique la

opción BINDFILE. La opción PACKAGE le permite especificar un nombre de

paquete para el paquete que se crea en el momento de la precompilación.

A continuación se muestra un ejemplo típico de cómo utilizar el mandato BIND.

Para vincular un archivo de vinculación denominado filename.bnd a la base de

datos, puede emitir el siguiente mandato:

BIND filename.bnd

Se crea un paquete para cada módulo de código fuente precompilado por

separado. Si una aplicación tiene cinco archivos fuente, de los cuales tres necesitan

precompilación, se crean tres paquetes o archivos de vinculación. Por omisión, a

cada paquete se le asigna un nombre que coincide con el nombre del módulo

fuente a partir del cual se ha originado el archivo .bnd, pero truncado a 8

caracteres. Para especificar de forma explícita otro nombre de paquete, debe

utilizar la opción PACKAGE USING en el mandato PREP. La versión de un paquete

la proporciona la opción de precompilación VERSION y su valor por omisión es

una serie vacía. Si el nombre y esquema de este paquete recién creado coinciden


con el nombre de un paquete que existe actualmente en la base de datos de

destino, pero el identificador de versión difiere, se crea un paquete nuevo y se

conserva el paquete anterior. Sin embargo, si existe un paquete cuyo nombre,

esquema y versión coinciden con los del paquete que se está vinculando, el

paquete se elimina y se sustituye por el paquete nuevo que se está vinculando (si

se especifica ACTION ADD en la vinculación se evita que se devuelva un error

(SQL0719)).








Revinculación de paquetes existentes con el mandato REBIND

Revincular es el proceso de volver a crear un paquete correspondiente a un

programa de aplicación que se había vinculado previamente. Debe revincular

paquetes si se han marcado como no válidos o no operativos o si las estadísticas

de base de datos han cambiado desde la última vinculación. Sin embargo, en

algunas situaciones es posible que desee revincular paquetes que son válidos. Por

ejemplo, es posible que desee aprovechar un índice recién creado o utilizar

estadísticas actualizadas después de ejecutar el mandato RUNSTATS.

Los paquetes pueden depender de varios tipos de objetos de bases de datos como

tablas, vistas, alias, índices, activadores, restricciones referenciales y restricciones de

comprobación de tabla. Si un paquete depende de un objeto de base de datos

(como una tabla, vista, activador, etc) y dicho objeto se elimina, el paquete se

coloca en estado no válido. Si el objeto que se elimina es una UDF, el paquete se

coloca en estado no operativo.

El gestor de bases de datos revincula de forma implícita (o automática) los

paquetes no válidos cuando se ejecutan. Los paquetes no operativos se deben

revincular de forma explícita ejecutando el mandato BIND o el mandato REBIND.

Tenga que cuenta que la revinculación implícita puede ocasionar errores

inesperados si la revinculación implícita falla. Es decir, se devuelve el error de

revinculación implícita en la sentencia que se ejecuta, que puede no ser la sentencia

que realmente contiene el error. Si se intenta ejecutar un paquete no operativo, se

produce un error. Puede decidir revincular de forma explícita paquetes no válidos

en lugar de dejar que el sistema los revincule automáticamente. Esto le permite

controlar cuándo se produce la revinculación.

La opción de qué mandato utilizar para revincular de forma explícita un paquete

depende de las circunstancias. Debe utilizar el mandato BIND para revincular un

paquete correspondiente a un programa que se ha modificado para incluir más o

menos sentencias de SQL o sentencias de SQL modificadas. También debe utilizar

el mandato BIND si tiene que cambiar opciones de vinculación con respecto a los

valores con los que se vinculó originalmente el paquete. En todos los demás casos,

utilice el mandato BIND o REBIND. Debe utilizar REBIND cuando la situación no

necesite de forma específica el uso de BIND, puesto que el rendimiento de REBIND es

significativamente mejor que el de BIND.


Si coexisten varias versiones del mismo nombre de paquete en el catálogo, no se

puede revincular más una versión simultáneamente.


v “Statement dependencies when changing objects” en Administration Guide:

Implementation


página 210



v “Mandato REBIND” en Consulta de mandatos

v “Mandato RUNSTATS” en Consulta de mandatos

Consideraciones sobre la vinculación

Si la página de códigos de la aplicación utiliza una página de códigos distinta de la

de la base de datos, es posible que deba tener en cuenta qué página de códigos

utilizar al vincular.

Si la aplicación emite llamadas a alguna de las API de programas de utilidad del

gestor de bases de datos, como por ejemplo IMPORT o EXPORT, debe vincular los

archivos de vinculación suministrados por el programa de utilidad a la base de

datos.

Puede utilizar opciones de vinculación para controlar determinadas operaciones

que se producen durante la vinculación, como en los siguientes ejemplos:

v La opción de vinculación QUERYOPT aprovecha una clase de optimización

específica al vincular.

v La opción de vinculación EXPLSNAP almacena información de instantánea de

Explain para las sentencias de SQL que se pueden elegir en las tablas de

Explain.

v La función de vinculación FUNCPATH resuelve correctamente tipos

diferenciados definidos por el usuario y funciones definidas por el usuario en

SQL estático.

Si el proceso de vinculación comienza pero nunca vuelve, es posible que otras

aplicaciones conectadas a la base de datos mantengan bloqueos que necesita. En

este caso, asegúrese de que no haya aplicaciones conectadas a la base de datos. Si

las hay, desconecte todas las aplicaciones en el servidor y el proceso de vinculación

continuará.

Si la aplicación va a acceder a un servidor utilizando DB2 Connect, puede utilizar

las opciones de BIND disponibles para dicho servidor.

Los archivos de vinculación no son compatibles con versiones anteriores de DB2

UDB para Linux, UNIX y Windows. En entornos de nivel mixto, DB2 sólo puede

utilizar las funciones disponibles al nivel inferior del entorno de base de datos. Por

ejemplo, si un cliente de la versión 8 se conecta a un servidor de la versión 7.2, el

cliente sólo podrá utilizar funciones de la versión 7.2. Como los archivos de

vinculación expresan las funciones de la base de datos, están sujetos a la restricción

de nivel mixto.


Si tiene que volver a vincular archivos de vinculación de nivel superior en sistemas

de nivel inferior, puede:

v Utilizar un Cliente DB2 de nivel inferior con el servidor de nivel superior y crear

archivos de vinculación que se puedan suministrar y vincular al entorno de DB2

UDB para Linux, UNIX y Windows de nivel inferior.

v Utilizar un cliente DB2 de nivel superior en el entorno de producción de nivel

inferior para vincular los archivos de vinculación de nivel superior creados en el

entorno de prueba. El cliente de nivel superior sólo pasa las opciones que se

aplican al servidor de nivel inferior.




v “Substituciones de caracteres durante conversiones de páginas de códigos” en


v “Factor de expansión de conversión de páginas de códigos” en Desarrollo de SQL

y rutinas externas

v “Página de códigos activa para la precompilación y vinculación” en Desarrollo de



v “Binding utilities to the database” en Administration Guide: Implementation



v “Sentencia SET CURRENT QUERY OPTIMIZATION” en Consulta de SQL,

Volumen 2

Ventajas de la vinculación diferida

La precompilación con la vinculación habilitada permite que una aplicación acceda

únicamente a la base de datos utilizada durante el proceso de precompilación. Sin

embargo, la precompilación con vinculación diferida permite que una aplicación

acceda a muchas bases de datos, puesto que puede vincular el archivo BIND

contra cada una. Este método de desarrollo de aplicaciones es más flexible por el

hecho de que las aplicaciones sólo se precompilan una vez, pero la aplicación se

puede vincular a una base de datos en cualquier momento.

Utilizar la API BIND durante la ejecución permite que una aplicación se vincule a

sí misma, quizás como parte de un procedimiento de instalación o antes de que se

ejecute un módulo asociado. Por ejemplo, una aplicación puede realizar varias

tareas, de las cuales sólo una necesita el uso de sentencias de SQL. Puede diseñar

la aplicación de modo que se vincule a sí misma a una base de datos sólo cuando

la aplicación llame a la tarea que necesita sentencias de SQL y sólo si aún no existe

un paquete asociado.

Otra ventaja del método de vinculación diferida es que le permite crear paquetes

sin suministrar el código fuente a los usuarios finales. Puede suministrar los

archivos de vinculación asociados con la aplicación.



página 58



v “API sqlabndx - Vincular programa de aplicaciones para crear un paquete” en

Consulta de las API administrativas

Mejoras en el rendimiento cuando se utiliza la opción REOPT

del mandato BIND

la opción de vinculación REOPT puede mejorar significativamente el rendimiento

de las aplicaciones de SQL incorporado. A continuación encontrará descripciones

correspondientes a SQL estático e incorporado.

Efectos de REOPT en SQL estático:

La opción de vinculación REOPT puede hacer que sentencias de SQL estático que

contengan variables de lenguaje principal o registros especiales se comporten como

sentencias de vinculación incremental. Esto significa que estas sentencias se

compilan cuando se ejecuta EXECUTE u OPEN, en lugar de hacerlo durante la

vinculación. Durante esta compilación, se selecciona el plan de acceso, de acuerdo

con los valores reales de estas variables.

Cuando se utiliza REOPT ONCE, el plan de acceso se coloca en antememoria

después de la primera petición OPEN o EXECUTE, y se utiliza para la ejecución

subsiguiente de esta sentencia. Cuando se utiliza REOPT ALWAYS, el plan de

acceso se regenera para cada petición OPEN y EXECUTE, y para crear el plan se

utiliza el conjunto actual de valores de variables de lenguaje principal, marcadores

de parámetros y registros especiales.

Efectos de REOPT en SQL dinámico:

Cuando especifica la opción REOPT ALWAYS, DB2 aplaza la preparación de

cualquier sentencia que contenga variables de lenguaje principal, marcadores de

parámetros y registros especiales hasta que DB2 encuentre una sentencia OPEN o

EXECUTE; es decir, cuando los valores de esas variables pasan a ser conocidos. En

ese momento, se genera el plan de acceso utilizando esos valores. Las peticiones

OPEN o EXECUTE subsiguientes para la misma sentencia recompilarán la

sentencia, reoptimizarán el plan de consulta utilizando el conjunto actual de

valores de las variables y ejecutarán el plan de consulta recién creado.

La opción REOPT ONCE tiene un efecto similar, salvo que el plan se optimiza una

sola vez utilizando los valores de las variables de lenguaje principal, marcadores

de parámetros y de registros especiales. Este plan se coloca en antememoria y es

utilizado por peticiones subsiguientes.





v “Utilización de registros especiales para controlar el entorno de compilación de

sentencias” en la página 214


página 74


204


Almacenamiento y mantenimiento de paquetes

Almacenamiento y mantenimiento de paquetes

Los paquetes se crean al precompilar/enlazar un programa de aplicación. El

paquete contiene un plan de acceso optimizado que supervisa la ejecución de todas

las sentencias de SQL que se encuentran dentro de la aplicación. Los tres tipos de

privilegios relacionados con los paquetes son CONTROL, EXECUTE y BIND y sirven para

filtrar el nivel de acceso aceptable. Se pueden crear varias versiones del mismo

paquete especificando la opción VERSION en el momento de la compilación. Esta

opción ayuda a evitar errores de falta de coincidencia de indicación de hora y

permite ejecutar simultáneamente varias versiones de la aplicación.


v “Creación de versiones de paquetes” en la página 219

v “Resolución de nombres de tabla no calificados” en la página 220

Creación de versiones de paquetes

Si tiene que crear varias versiones de una aplicación, puede utilizar la opción

VERSION del mandato PRECOMPILE. Esta opción permite la coexistencia de

varias versiones del mismo nombre de paquete (es decir, el nombre del paquete y

el nombre del creador). Por ejemplo, supongamos que tiene una aplicación

denominada foo que se compila desde foo.sqc. Precompilaría y vincularía el

paquete foo a la base de datos y distribuiría la aplicación a los usuarios. Luego los

usuarios podrían ejecutar la aplicación. Para realizar cambios en la aplicación,

actualizaría foo.sqc y luego repetiría el proceso de recompilación, vinculación y

envío de la aplicación a los usuarios. Si no se especifica la opción VERSION para

la primera o segunda precompilación de foo.sqc, el primer paquete se sustituye

por el segundo. Cualquier usuario que intente ejecutar la versión antigua de la

aplicación recibirá un error SQLCODE -818, que indica un error de falta de

coincidencia de indicación horaria.

Para evitar el error de falta de coincidencia de indicación horaria y para permitir

que ambas versiones de la aplicación se ejecutan al mismo tiempo, utilice la

creación de versiones de paquetes. Como ejemplo, cuando cree la primera versión

de foo, precompílela utilizando la opción VERSION, del siguiente modo:

DB2 PREP FOO.SQC VERSION V1.1

Ahora se puede ejecutar esta primera versión del programa. Cuando cree la nueva

versión de foo, precompílela con el mandato:

DB2 PREP FOO.SQC VERSION V1.2

En este momento esta nueva versión de la aplicación también se ejecutará, aunque

aún se estén ejecutando instancias de la primera aplicación. Puesto que la versión

de paquete correspondiente al primer paquete es V1.1 y la versión de paquete

correspondiente al segundo es V1.2, no hay conflicto de nombres: ambos paquetes

existirán en la base de datos y ambas versiones de la aplicación se pueden utilizar.

Puede utilizar la opción ACTION de los mandatos PRECOMPILE o BIND junto

con la opción VERSION del mandato PRECOMPILE. La opción ACTION sirve

para controlar el modo en que las distintas versiones de paquetes se pueden añadir

o sustituir.


Los privilegios de paquetes no tienen granularidad a nivel de versión. Es decir,

una acción GRANT o REVOKE de un privilegio de paquete se aplica a todas las

versiones de un paquete que comparten el nombre y el creador. Así, si se otorgaran

los privilegios del paquete foo a un usuario o un grupo después de que se creara

la versión V1.1, cuando se distribuyera la versión V1.2 el usuario o grupo tendría

los mismos privilegios sobre la versión V1.2. Este comportamiento suele ser

necesario porque normalmente los mismos usuarios y grupos tienen los mismos

privilegios sobre todas las versiones de un paquete. Si no desea que se apliquen los

mismos privilegios de paquete a todas las versiones de una aplicación, no utilice la

opción PRECOMPILE VERSION al realizar versiones del paquete. En su lugar,

utilice distintos nombres de paquetes (cambiando el nombre del archivo fuente

actualizado o utilizando la opción PACKAGE USING para cambiar el nombre del

paquete de forma explícita).











Resolución de nombres de tabla no calificados

Puede manejar nombres de tabla no calificados en la aplicación utilizando uno de

los siguientes métodos:

v Cada usuario puede vincular su paquete con distintos parámetros de

COLLECTION que utilizan distintos identificadores de autorización mediante

los siguientes mandatos:

CONNECT TO db_name USER user_name

BIND file_name COLLECTION schema_name

En el ejemplo anterior, db_name es el nombre de la base de datos, user_name es el

nombre del usuario y file_name es el nombre de la aplicación que se va a

vincular. Tenga en cuenta que user_name y schema_name suelen tener el mismo

valor. Luego utilice la sentencia SET CURRENT PACKAGESET para especificar

qué paquete utilizar y, por lo tanto, qué calificadores se utilizarán. Si no se

especifica COLLECTION, el calificador por omisión es el identificador de

autorización que se utiliza al vincular el paquete. Si se especifica COLLECTION,

el schema_name especificado es el calificador que se utilizará para objetos no

calificados.

v Cree vistas para cada usuario con el mismo nombre que la tabla de modo que

los nombres de tabla no calificados se resuelvan correctamente.

v Cree un alias para que cada usuario apunte a la tabla deseada.



v “Sentencia SET CURRENT PACKAGESET” en Consulta de SQL, Volumen 2

v “Sentencia CREATE ALIAS” en Consulta de SQL, Volumen 2


v “Sentencia CREATE VIEW” en Consulta de SQL, Volumen 2

Creación de aplicaciones de SQL incorporado mediante el script de

creación de ejemplo

Creación de aplicaciones de SQL incorporado mediante el

script de creación de ejemplo

Los archivos utilizados para mostrar la creación de programas de ejemplo se

conocen como archivos script en UNIX y Linux y como archivos de proceso por

lotes en Windows. Nosotros los llamaremos genéricamente archivos de creación.

Estos archivos contienen los mandatos de compilación y enlace recomendados para

los compiladores de las plataformas soportadas.

DB2 proporciona archivos de creación para los lenguajes principales pertenecientes

a las plataformas soportadas. Los archivos de creación están disponibles en el

mismo directorio en el que se encuentran los ejemplos correspondientes a cada

lenguaje. La tabla siguiente muestra los diferentes tipos de archivos de creación

para crear diversos tipos de programas. A menos que se indique otra cosa, estos

archivos de creación están pensados para los lenguajes soportados en todas las

plataformas soportadas. Los archivos de creación tienen la extensión .bat (batch)

en Windows, la cual no se muestra en la tabla. No existe extensión de archivo para

las plataformas UNIX.

Tabla 22. Archivos de creación de DB2

Archivo de

creación Tipos de programas creados

bldapp Programas de aplicación

bldrtn Rutinas (procedimientos almacenados y funciones definidas por el

usuario)

bldmc Aplicaciones C/C++ de conexión múltiple

bldmt Aplicaciones C/C++ de varias hebras

bldcli Aplicaciones cliente de CLI para procedimientos SQL contenidos en

el subdirectorio sqlproc de samples.

Nota: Por omisión, los scripts de ejemplo de bldapp para crear archivos ejecutables

a partir de código fuente crearán archivos ejecutables de 64 bits.

La tabla siguiente lista los archivos de creación correspondientes a cada plataforma

y lenguaje de programación, y los directorios donde están situados. En la

documentación en línea, los nombres de los archivos de creación están enlazados

dinámicamente con los archivos fuente de HTML. El usuario puede también

acceder a los archivos de texto contenidos en los directorios samples

correspondientes.


Tabla 23. Archivos de creación por lenguaje y plataforma

Plataforma —>

Lenguaje AIX HP-UX Linux Solaris Windows

C

samples/c

bldapp

bldrtn

bldmt

bldmc

bldapp

bldrtn

bldmt

bldmc

bldapp

bldrtn

bldmt

bldmc

bldapp

bldrtn

bldmt

bldmc

bldapp.bat

bldrtn.bat

bldmt.bat

bldmc.bat

C++

samples/cpp

bldapp

bldrtn

bldmt

bldmc

bldapp

bldrtn

bldmt

bldmc

bldapp

bldrtn

bldmt

bldmc

bldapp

bldrtn

bldmt

bldmc

bldapp.bat

bldrtn.bat

bldmt.bat

bldmc.bat

IBM COBOL

samples/cobol

bldapp

bldrtn

n/d n/d n/d bldapp.bat

bldrtn.bat

Micro Focus COBOL

samples/cobol_mf

bldapp

bldrtn

bldapp

bldrtn

bldapp

bldrtn

bldapp

bldrtn

bldapp.bat

bldrtn.bat

Los archivos de creación se utilizan en la documentación sobre la creación de

aplicaciones y rutinas porque muestran muy claramente las opciones de

compilación y enlace que DB2 recomienda para los compiladores soportados

Generalmente existen otras muchas opciones de compilación y enlace, que el

usuario puede probar. Consulte la documentación del compilador para conocer

todas las opciones de compilación y enlace proporcionadas. Además de crear los

programas de ejemplo, el programador puede también crear sus propios

programas mediante los archivos de creación. Los programas de ejemplo se

pueden utilizar como plantillas que el usuario puede modificar como ayuda en el

desarrollo de aplicaciones.

Una característica práctica de los archivos de creación es que están diseñados para

crear un archivo fuente cuyo nombre puede ser cualquier nombre de archivo

permitido por el compilador. En cambio, en los makefiles, los nombres de

programa están codificados en el archivo. Los makefiles acceden a los archivos de

creación para compilar y enlazar los programas que crean. Los archivos de creación

utilizan la variable $1 en UNIX y Linux y la variable %1 en los sistemas operativos

Windows para que internamente se utilice la variable en lugar del nombre de

programa. Mediante un mayor número de estos nombres de variable se sustituyen

otros argumentos que puedan ser necesarios.

Los archivos de creación permiten experimentar de forma rápida y sencilla, pues

cada archivo está pensado para una clase específica de creación de programas,

tales como la creación de programas autónomos, rutinas (procedimientos

almacenados y funciones definidas por el usuario) o tipos de programa más

especializados, tales como los programas de conexión múltiple o los programas de

varias hebras. Se proporciona cada tipo de archivo de creación siempre que el

compilador da soporte a la clase determinada de programa para el que está

diseñado el archivo de creación.

El archivo objeto y el archivo ejecutable creados por un archivo de creación se

sobrescriben cada vez que se crea un programa, aunque el archivo fuente no se

modifique.No ocurre así cuando se utiliza un makefile. Por tanto, el programador

puede volver a crear un programa existente sin tener que suprimir un archivo

objeto o archivo ejecutable anterior, ni modificar el archivo fuente.

Los archivos de creación contienen un valor por omisión para la base de datos

″sample″ (base de datos de ejemplo). Si el usuario desea acceder a otra base de


datos, puede simplemente proporcionar otro parámetro para alterar temporalmente

el valor por omisión. Si utilizan regularmente la otra base de datos, pueden

codificar el nombre de esa base de datos, en lugar de sample, dentro del propio

archivo de creación.

Para programas de SQL incorporado, salvo cuando se utilice el precompilador

COBOL de IBM en Windows, los archivos de creación llamar a otro archivo,

embprep, que contiene los pasos de precompilación y enlace para los programas de

SQL incorporado. Para estos pasos pueden ser necesarios los parámetros

opcionales correspondientes al ID de usuario y la contraseña, según el lugar donde

se cree el programa de SQL incorporado.

Por último, el programador puede modificar los archivos de creación de acuerdo

con sus necesidades. Además de cambiar el nombre de la base de datos dentro del

archivo de creación (tal como se describió anteriormente), el programador puede

codificar fácilmente otros parámetros dentro del archivo, cambiar opciones de

compilación y enlace, o modificar la vía de instancia predefinida de DB2. El

carácter simple, directo y específico del archivo de creación hace que el usuario

pueda adaptarlo fácilmente a sus necesidades.


v “Archivos de ejemplo” en Temas de ejemplos

v “El entorno de desarrollo de aplicaciones de bases de datos de DB2” en Iniciación

al desarrollo de aplicaciones de bases de datos




página 74



página 209

Programas de utilidad de comprobación de errores

El Cliente DB2 proporciona varios archivos de programas de utilidad. Estos

archivos contienen funciones para la comprobación de errores y la impresión de

información de errores. Los archivos de programa de utilidad correspondientes a

cada lenguaje se encuentran en el directorio ″samples″. Cuando se utilizan junto

con un programa de aplicación, los archivos de los programas de utilidad de

comprobación de errores proporcionan información útil sobre errores y facilitan la

depuración de los programas DB2. La mayoría de los programas de comprobación

de errores utilizan las API de DB2 GET SQLSTATE MESSAGE (sqlogstt) y GETERROR

MESSAGE (sqlaintp) para obtener la información pertinente de SQLSTATE y SQLCA

referente a problemas encontrados al ejecutar el programa. El archivo de programa

de utilidad de la CLI de DB2, utilcli.c, no hace uso de estas API de DB2; en su

lugar utiliza sentencias equivalentes de la CLI de DB2. Todos los programas de

utilidad de comprobación de errores imprimen mensajes de error descriptivos para

ayudar al programador a comprender rápidamente el problema. Algunos

programas DB2, tales como las rutinas (procedimientos almacenados y funciones

definidas por el usuario), no necesitan hacer uso de los programas de utilidad.


A continuación se indican los archivos de los programas de utilidad de

comprobación de errores utilizados por los compiladores soportados por DB2 para

los diversos lenguajes de programación:

Tabla 24. Archivos del programa de utilidad de comprobación de errores por idioma

Idioma

Archivo fuente

de SQL no

incorporado

Archivo de

cabecera de SQL

no incorporado

Archivo fuente

de SQL

incorporado

Archivo de

cabecera de SQL

incorporado

C

samples/c

utilapi.c utilapi.h utilemb.sqc utilemb.h

C++

samples/cpp

utilapi.C utilapi.h utilemb.sqC utilemb.h

IBM COBOL

samples/cobol

checkerr.cbl n/a n/a n/a

Micro Focus COBOL

samples/cobol_mf

checkerr.cbl n/a n/a n/a

Para poder utilizar las funciones del programa de utilidad, se debe primero

compilar el archivo del programa de utilidad y luego enlazar su archivo objeto

durante la creación del archivo ejecutable del programa destino. Tanto el makefile

como los archivos de creación contenidos en los directorios samples realizan esas

acciones para los programas que necesitan hacer uso de los programas de utilidad

de comprobación de errores.

El ejemplo siguiente muestra cómo se utilizan los programas de utilidad de

comprobación de errores en los programas DB2. El archivo de cabecera utilemb.h

define la macro EMB_SQL_CHECK, para las funciones SqlInfoPrint() y

TransRollback():

/* macro para la comprobación del SQL incorporado */

#define EMB_SQL_CHECK( MSG_STR ) \

SqlInfoPrint(MSG_STR, &sqlca, __LINE__, __FILE__); \

if (sqlca.sqlcode < 0) \

{ \

TransRollback(); \

return 1; \

}

SqlInfoPrint() comprueba el SQLCODE y muestra la información disponible

relacionada con el error específico encontrado. También indica el lugar donde se

produjo el error en el código fuente. TransRollback() permite que el archivo de

programa de utilidad retrotraiga sin peligro una transacción donde se ha

producido un error. Utiliza la sentencia de SQL incorporado EXEC SQL ROLLBACK. El

ejemplo siguiente nuestra cómo el programa de C dbuse invoca las funciones del

programa de utilidad utilizando la macro, y proporciona el valor "Delete with

host variables -- Execute" para el parámetro MSG_STR de la función

SqlInfoPrint():

EXEC SQL DELETE FROM org

WHERE deptnumb = :hostVar1 AND

division = :hostVar2;

EMB_SQL_CHECK("Delete with host variables -- Execute");

La macro EMB_SQL_CHECK hace que si la sentencia DELETE falla, la transacción se

retrotraiga sin peligro, y se imprima el mensaje de error apropiado.

El programador puede utilizar estos programas de utilidad de comprobación de

errores y utilizarlos como modelo al crear sus propios programas DB2.







página 190





Creación de aplicaciones y rutinas escritas en C y C++

Creación de aplicaciones y rutinas escritas en C y C++

Se proporcionan scripts de creación para distintas plataformas de sistemas

operativos con el producto para facilitar la creación de aplicaciones de SQL

incorporado en C y C++. Además de los scripts de creación utilizados para crear

aplicaciones, se proporciona un script específico, bldrtn, que sirve para crear

rutinas (procedimientos almacenados y funciones definidas por el usuario). Para

aplicaciones y rutinas escritas en VisualAge, se utilizan archivos de configuración

para crear las aplicaciones. Los ejemplos de aplicaciones C suministrados varían

desde ejemplos de nivel de guía de aprendizaje o de cliente hasta ejemplo de nivel

de instancia y se encuentran en el directorio sqllib/samples/c para UNIX y en el

directorio sqllib\samples\c para Windows.




v “Creación del código de rutinas C y C++” en la página 362

v “Creación de aplicaciones de SQL incorporado escritas en VisualAge C++ con

archivos de configuración” en la página 229

Creación de aplicaciones en C o C++ mediante el script de

creación de ejemplo (UNIX)

DB2 proporciona scripts de creación para compilar y enlazar programas de SQL

incorporado y de la API de administración de DB2 en C o C++. Se encuentran en

el directorio sqllib/samples/c para aplicaciones en C y en el directorio

sqllib/samples/cpp para aplicaciones en C++, junto con programas de ejemplo

que se pueden crear con estos archivos.

El archivo de creación, bldapp contiene los mandatos para crear un programa de

aplicación DB2.

El primer parámetro, $1, especifica el nombre del archivo fuente. Éste es el único

parámetro necesario para los programas de la API de administración de DB2 que

no contienen SQL incorporado. Para crear programas de SQL incorporado es

necesaria una conexión con la base de datos, por lo que también se proporcionan

otros tres parámetros opcionales: el segundo parámetro, $2, especifica el nombre de

la base de datos con la que se desea conectar; el tercer parámetro, $3, especifica el

ID de usuario correspondiente a la base de datos, y $4 especifica la contraseña.


Para un programa de SQL incorporado, bldapp pasa los parámetros al script de

precompilación y vinculación, embprep. Si no se proporciona un nombre de base de

datos, se utiliza la base de datos por omisión sample. Los parámetros de ID de

usuario y contraseña sólo son necesarios si la instancia donde se crea el programa

es diferente de la instancia donde reside la base de datos.

Procedimiento:

Los ejemplos siguientes muestran cómo crear y ejecutar programas de la API de

administración de DB2 y aplicaciones de SQL incorporado.

Creación y ejecución de aplicaciones de la API de administración de DB2

Para crear el programa de ejemplo de la API de administración de DB2, cli_info,

a partir del archivo fuente cli_info.c para C y cli_info.C para ++, especifique:

bldapp cli_info

El resultado es un archivo ejecutable, cli_info.

Para ejecutar el archivo ejecutable, escriba el nombre del ejecutable:

cli_info

Creación y ejecución de aplicaciones de SQL incorporado

Hay tres formas de crear la aplicación de SQL incorporado, tbmod , a partir del

archivo fuente tbmod.sqc para C y tbmod.sqC para C++,:

1. Si conecta con la base de datos ″sample″ en la misma instancia, especifique:

bldapp tbmod

2. Si conecta con otra base de datos en la misma instancia, especifique también el

nombre de la base de datos:

bldapp tbmod basedatos

3. Si conecta con una base de datos de otra instancia, especifique también el ID de

usuario y la contraseña de la instancia de base de datos:

bldapp tbmod basedatos IDusuario contraseña

El resultado es un archivo ejecutable, tbmod.

Existen tres maneras de ejecutar esta aplicación de SQL incorporado:

1. Si desea acceder a la base de datos sample en la misma instancia, especifique

simplemente el nombre del ejecutable:

tbmod

2. Si desea acceder a otra base de datos en la misma instancia, especifique el

nombre del ejecutable y el nombre de la base de datos:

tbmod basedatos

3. Si desea acceder a una base de datos de otra instancia, especifique el nombre

del ejecutable, el nombre de la base de datos, y el ID de usuario y la contraseña

de la instancia de base de datos:

tbmod basedatos IDusuario contraseña






v “Creación de rutinas en C o C++ mediante el script de creación de ejemplo



v “Opciones de compilación y enlace de aplicaciones de API de DB2 y de SQL

incorporado de C de AIX” en la página 234

v “Opciones de compilación y enlace para aplicaciones C de HP-UX” en la página

236

v “Opciones de compilación y enlace para aplicaciones C de Linux” en la página

239

v “Opciones de compilación y enlace para aplicaciones C de Solaris” en la página

242


v “bldapp -- Builds AIX C application programs (C)”

v “bldapp -- Builds HP-UX C applications (C)”

v “bldapp -- Builds Linux C applications (C)”

v “bldapp -- Builds Solaris C applications (C)”

v “cli_info.c -- Set and get information at the client level (C)”

v “embprep -- To prep and bind C/C++ and Micro Focus COBOL embedded SQL

programs (C)”


Creación de aplicaciones C/C++ en Windows

DB2 proporciona scripts de creación para compilar y enlazar programas de la API

de DB2 y de SQL incorporado en C/C++. Estos archivos residen en los directorios

sqllib/samples/c y sqllib\samples\cpp, junto con programas de ejemplo que se

pueden crear a partir de esos archivos.

El archivo de proceso por lotes bldapp.bat contiene los mandatos para crear

programas de la API de DB2 y de SQL incorporado. Utiliza un máximo de cuatro

parámetros como entrada, que están representados dentro del archivo de proceso

por lotes por las variables %1, %2, %3 y %4.

El primer parámetro, %1, especifica el nombre del archivo fuente. Éste es el único

parámetro necesario para los programas que no contienen SQL incorporado. Para

crear programas de SQL incorporado es necesaria una conexión con la base de

datos, por lo que también se proporcionan otros tres parámetros: el segundo

parámetro, %2, especifica el nombre de la base de datos con la que se desea

conectar; el tercer parámetro, %3, especifica el ID de usuario correspondiente a la

base de datos, y %4 especifica la contraseña.

Para un programa de SQL incorporado, bldapp pasa los parámetros al archivo de

precompilación y vinculación, embprep.bat. Si no se proporciona un nombre de

base de datos, se utiliza la base de datos por omisión sample. Los parámetros de

ID de usuario y contraseña sólo son necesarios si la instancia donde se crea el

programa es diferente de la instancia donde reside la base de datos.

Procedimiento:



DB2 y aplicaciones de SQL incorporado.

Para crear el programa de ejemplo de la API de DB2 de SQL no incorporado,

cli_info, a partir del archivo fuente cli_info.c, situado en sqllib\samples\c, o a

partir del archivo fuente cli_info.cxx, situado en sqllib\samples\cpp, especifique:

bldapp cli_info

El resultado es un archivo ejecutable, cli_info.exe. Puede ejecutar el archivo

ejecutable escribiendo el nombre del ejecutable (sin la extensión) en la línea de

mandatos:

cli_info


Existen tres maneras para crear la aplicación de SQL incorporado tbmod, a partir

del archivo fuente C tbmod.sqc de sqllib\samples\c, o partir del archivo C++

tbmod.sqx de sqllib\samples\cpp:


bldapp tbmod



bldapp tbmod basedatos



bldapp tbmod basedatos IDusuario contraseña

El resultado es un archivo ejecutable, tbmod.exe.




tbmod



tbmod basedatos




tbmod basedatos IDusuario contraseña

Creación y ejecución de aplicaciones de varias hebras

Las aplicaciones C/C++ de varias hebras en Windows se tienen que compilar con

las opciones -MT o -MD. La opción -MT se enlazará utilizando la biblioteca estática

LIBCMT.LIB, y -MD se enlazará utilizando la biblioteca dinámica MSVCRT.LIB. El

binario enlazado con -MD será más pequeño pero dependiente de MSVCRT.DLL,

mientras que el binario enlazado con -MT será más grande pero independiente

respecto al momento de ejecución.


El archivo de proceso por lotes bldmt.bat utiliza la opción -MT para crear un

programa de varias hebras. Todas las otras opciones de compilación y enlace son

iguales a las utilizadas por el archivo de proceso por lotes bldapp.bat para crear

aplicaciones autónomas normales.

Para crear el programa de varias hebras de ejemplo, dbthrds, a partir de los

archivos fuente samples\c\dbthrds.sqc o samples\cpp\dbthrds.sqx, especifique:

bldmt dbthrds

El resultado es un archivo ejecutable, dbthrds.exe.

Existen tres maneras de ejecutar esta aplicación de varias hebras:

1. Si accede a la base de datos sample en la misma instancia, especifique

simplemente el nombre del ejecutable (sin la extensión):

dbthrds



dbthrds basedatos




dbthrds basedatos IDusuario contraseña


v “Opciones de compilación y enlace para aplicaciones C y C++ de Windows” en

la página 245


v “cli_info.C -- Set and get information at the client level (C++)”

v “dbthrds.sqC -- How to use multiple context APIs on Windows (C++)”

v “tbmod.sqC -- How to modify table data (C++)”

v “bldapp.bat -- Builds C++ applications on Windows”

v “bldmt.bat -- Builds C++ multi-threaded applications on Windows”

v “dbthrds.sqc -- How to use multiple context APIs on Windows (C)”

v “embprep.bat -- Prep and binds a C/C++ or Micro Focus COBOL embedded

SQL program on Windows”


v “bldapp.bat -- Builds C applications on Windows”

v “bldmt.bat -- Builds C multi-threaded applications on Windows”

v “cli_info.c -- Set and get information at the client level (C)”

Creación de aplicaciones de SQL incorporado escritas en

VisualAge C++ con archivos de configuración

VisualAge C++ tiene un compilador incremental y un compilador de proceso por

lotes. Mientras que el compilador de proceso por lotes utiliza makefiles y archivos

de creación, el compilador incremental utiliza archivos de configuración en su

lugar. Consulte la documentación de VisualAge C++ Versión 5.0 para conocer más

sobre este tema.

DB2 proporciona archivos de configuración para los diferentes tipos de programas

DB2 que el usuario puede crear con el compilador VisualAge C++.


Procedimiento:

Para utilizar un archivo de configuración de DB2, primero debe asignar una

variable de entorno al nombre del programa que desea compilar. A continuación,

compile el programa con un mandato proporcionado por VisualAge C++. Estos son

los temas que describen cómo utilizar los archivos de configuración

proporcionados por DB2 para compilar los diversos tipos de programas:

v Creación de aplicaciones de SQL incorporado y de la API de DB2 en C o C++

con archivos de configuración (AIX)

v Creación de procedimientos almacenados de SQL incorporado en C o C++ con

archivos de configuración

v Creación de funciones definidas por el usuario en C o C++ con archivos de

configuración (AIX)


v “Creación de aplicaciones de SQL incorporado y de API de DB2 en C o C++ con

archivos de configuración (AIX)” en la página 230

v “Creación de procedimientos almacenados de SQL incorporado en C o C++ con


v “Creación de funciones definidas por el usuario en C o C++ con archivos de

configuración (AIX)” en la página 386





Creación de aplicaciones de SQL incorporado y de API de DB2

en C o C++ con archivos de configuración (AIX)

Los archivos de configuración son básicamente scripts de creación utilizados para

crear aplicaciones escritas en VisualAge. El script hace varias cosas, que incluyen

comprobación de errores, conexión a una base de datos, precompilación del código,

establecimiento de la vía de acceso en la que se puede acceder a DB2 y finalmente

generación del archivo ejecutable.

Procedimiento:


administración de DB2 y aplicaciones de SQL incorporado con archivos de

configuración.

Creación de aplicaciones de SQL incorporado C y C++ con archivos de

configuración

El archivo de configuración emb.icc, contenido en sqllib/samples/c y

sqllib/samples/cpp, le permite crear aplicaciones de SQL incorporado para DB2

utilizando C o C++ en AIX.

Para utilizar el archivo de configuración a fin de crear la aplicación de SQL

incorporado tbmod, a partir del archivo fuente tbmod.sqc, siga estos pasos:

1. Asigne a la variable de entorno EMB el nombre del programa, de este modo:

v En el shell bash o Korn:

export EMB=tbmod


v En el shell C:

setenv EMB tbmod

2. Si su directorio de trabajo contiene un archivo emb.ics, resultante de la creación

de un programa diferente con el archivo emb.icc, suprima el archivo emb.ics

mediante este mandato:

rm emb.ics

Si para el mismo programa que ahora creará de nuevo ya existe un archivo

emb.ics, no es necesario suprimir el archivo.

3. Compile el programa de ejemplo, especificando:

vacbld emb.icc

Nota: El mandato vacbld está incluido en VisualAge C++.

El resultado es un archivo ejecutable, tbmod. Puede ejecutar el programa entrando

el nombre del ejecutable:

tbmod

Creación de aplicaciones de API de DB2 C y C++ con archivos de configuración

El archivo de configuración, api.icc en sqllib/samples/c y en

sqllib/samples/cpp, le permite crear programas de la API de administración de

DB2 en C o C++ en AIX.

Para utilizar el archivo de configuración para crear el programa de ejemplo de la

API de administración de DB2, cli_info, a partir del archivo fuente cli_info.c,

haga lo siguiente:

1. Asigne a la variable de entorno API el nombre del programa, de este modo:


export API=cli_info

v En el shell C:

setenv API cli_info

2. Si su directorio de trabajo contiene un archivo api.ics, resultante de la creación

de un programa diferente con el archivo api.icc, suprima el archivo api.ics


rm api.ics


api.ics, no es necesario suprimir el archivo.


vacbld api.icc


El resultado es un archivo ejecutable, cli_info. Puede ejecutar el programa

entrando el nombre del ejecutable:

cli_info








Creación de aplicaciones C/C++ de conexión múltiple en

Windows

DB2 proporciona scripts de creación para compilar y enlazar programas C y C++

de SQL incorporado y de los programas de API de DB2. Estos archivos residen en

los directorios sqllib/samples/c y sqllib\samples\cpp, junto con programas de

ejemplo que se pueden crear a partir de esos archivos.

El archivo de proceso por lotes, bldmc.bat, contiene los mandatos para crear un

programa de conexión múltiple de DB2, que requiere dos bases de datos. Las

opciones de compilación y enlace son las mismas que las utilizadas en el archivo

bldapp.bat.

El primer parámetro, %1, especifica el nombre del archivo fuente. El segundo

parámetro, %2, especifica el nombre de la primera base de datos a la que desea

conectarse. El tercer parámetro, %3, especifica la segunda base de datos a la que

desea conectarse. Todos estos parámetros son obligatorios.

Nota: El script de creación codifica los valores por omisión ″sample″ y ″sample2″

como nombres de la base de datos (%2 y %3, respectivamente) por lo que, si

está utilizando el script de creación y acepta estos valores, sólo tendrá que

especificar el nombre del programa (parámetro %1). Si utiliza el script

bldmc.bat debe especificar los tres parámetros.

No se requieren parámetros opcionales para una conexión local, pero sí para

conectar con un servidor desde un cliente remoto. Estos parámetros son: %4 y %5

para especificar, respectivamente, el ID de usuario y la contraseña para la primera

base de datos; y %6 y %7 para especificar, respectivamente, el ID de usuario y la

contraseña para la segunda base de datos.

Procedimiento:

Para el programa de ejemplo de conexión múltiple, dbmcon.exe, se requieren dos

bases de datos. Si aún no se ha creado la base de datos sample, la puede crear

entrando db2sampl en la línea de mandatos de una ventana de mandatos de DB2.

La segunda base de datos, aquí llamada sample2, se puede crear mediante uno de

los mandatos siguientes:

Si crea la base de datos localmente:

db2 create db sample2

Si crea la base de datos remotamente:

db2 attach to <nombre_nodo>

db2 create db sample2

db2 detach

db2 catalog db sample2 as sample2 at node <nombre_nodo>

donde <nombre_nodo es el nodo en que reside la base de datos.

Una conexión múltiple también requiere que se esté ejecutando el receptor TCP/IP.

Para asegurarse que es así, haga lo siguiente:

1. Establezca la variable de entorno DB2COMM en TCP/IP de la forma siguiente:


db2set DB2COMM=TCPIP

2. Actualice el archivo de configuración del gestor de bases de datos con el

nombre del servicio de TCP/IP que se haya especificado en el archivo de

servicios:

db2 update dbm cfg using SVCENAME <nombre del servicio de TCP/IP>

Cada instancia tiene un nombre de servicio TCP/IP listado en el archivo de

servicios. Si no puede localizarlo o no tiene el permiso de archivo para cambiar

el archivo de servicios, pida ayuda al administrador.

3. Detenga y reinicie el gestor de bases de datos para que estos cambios entren en

vigor:

db2stop

db2start

El programa dbmcon.exe se crea a partir de cinco archivos de los directorios

samples\c o samples\cpp:

dbmcon.sqc o dbmcon.sqx

Archivo fuente principal para conectar con ambas bases de datos.

dbmcon1.sqc o dbmcon1.sqx

Archivo fuente para crear un paquete vinculado a la primera base de

datos.

dbmcon1.h

Archivo de cabecera para dbmcon1.sqc o dbmcon1.sqx, incluido en el

archivo fuente principal, dbmcon.sqc o dbmcon.sqx, para acceder a las

sentencias de SQL para crear y eliminar una tabla que se debe vincular a la

primera base de datos.

dbmcon2.sqc o dbmcon2.sqx

Archivo fuente para crear un paquete vinculado a la segunda base de

datos.

dbmcon2.h

Archivo de cabecera para dbmcon2.sqc o dbmcon2.sqx, incluido en el

archivo fuente principal, dbmcon.sqc o dbmcon.sqx, para acceder a las

sentencias de SQL para crear y eliminar una tabla que se debe vincular a la

segunda base de datos.

Para crear el programa de ejemplo de conexión múltiple, dbmcon.exe, se entre lo

siguiente:

bldmc dbmcon sample sample2

El resultado es un archivo ejecutable, dbmcon.exe.

Para ejecutar el archivo ejecutable, entre el nombre del ejecutable sin la extensión:

dbmcon

El programa muestra una confirmación en una fase para dos bases de datos.







la página 245

v “svcename - TCP/IP service name configuration parameter” en Performance

Guide


v “bldmc.bat -- Builds C multi-connection application on Windows”

v “dbmcon.sqc -- How to use multiple databases (C)”

v “dbmcon1.h -- Function declarations for the source file, dbmcon1.sqc (C)”

v “dbmcon1.sqc -- Functions used in the multiple databases program dbmcon.sqc

(C)”

v “dbmcon2.h -- Function declarations for the source file, dbmcon2.sqc (C)”

v “dbmcon2.sqc -- Functions used in the multiple databases program dbmcon.sqc

(C)”

v “bldmc.bat -- Builds C++ multi-connection application on Windows”

v “dbmcon.sqC -- How to use multiple databases (C++)”

v “dbmcon1.h -- Class declaration for the source file, dbmcon1.sqC (C++)”

v “dbmcon1.sqC -- Functions used in the multiple databases program dbmcon.sqC

(C++)”

v “dbmcon2.h -- Class declaration for the source file, dbmcon2.sqC (C++)”

v “dbmcon2.sqC -- Functions used in the multiple databases program dbmcon.sqC

(C++)”

Opciones de compilación y enlace de aplicaciones de API de

DB2 y de SQL incorporado de C de AIX

La tabla siguiente muestra las opciones de compilación y enlace que DB2

recomienda para crear aplicaciones C de SQL incorporado y de la API de DB2 con

el compilador C de IBM para AIX, tal como muestra el script de creación bldapp.

Opciones de compilación y enlace para bldapp:

Opciones de compilación:

xlc El compilador IBM XL C/C++.

$EXTRA_CFLAG

Contiene ″-q64″ para una instancia en que está habilitado el soporte de 64 bits; de

lo contrario, no contiene ningún valor.

-I$DB2PATH/include

Especifica la ubicación de los archivos de inclusión de DB2. Por ejemplo:

$HOME/sqllib/include.

-c Hace que se efectúe solamente la compilación, no la edición de enlaces. La

compilación y la edición de enlaces son pasos separados.


Opciones de enlace:

xlc Hace que el compilador se utilice como interfaz del editor de enlaces.

$EXTRA_CFLAG



-o $1 Especifica el programa ejecutable.

$1.o Especifica el archivo objeto del programa.

utilemb.o

Si es un programa de SQL incorporado, incluir el archivo objeto del programa de

utilidad de SQL incorporado para la comprobación de errores.

utilapi.o

Si crea un programa que no es de SQL incorporado, incluir el archivo objeto del

programa de utilidad de la API de DB2 para la comprobación de errores.

-ldb2 Enlazar con la biblioteca de DB2.

-L$DB2PATH/$LIB

Especifica la ubicación de las bibliotecas compartidas de tiempo de ejecución de

DB2. Por ejemplo: $HOME/sqllib/$LIB. Si el usuario no especifica la opción -L, el

compilador utiliza esta vía de acceso: /usr/lib:/lib.

Consulte la documentación del compilador para conocer otras opciones de compilador.





v “Opciones de compilación y enlace para rutinas C de AIX” en la página 373


v “bldapp -- Builds AIX C application programs (C)”

Opciones de compilación y enlace de aplicaciones de la API de

administración de DB2 y de SQL incorporado en C++ de AIX

A continuación se muestran las opciones de compilación y enlace que se

recomiendan para DB2 para crear aplicaciones de SQL incorporado y de la API de

administración de DB2 en C++ con el compilador IBM XL C/C++ de AIX, tal como

se muestra en el script de creación bldapp.



xlC El compilador IBM XL C/C++.

EXTRA_CFLAG



-I$DB2PATH/include






Opciones de enlace:

xlC Hace que el compilador se utilice como interfaz del editor de enlaces.

EXTRA_CFLAG





utilapi.o

Hace que se incluya el archivo objeto del programa de utilidad de la API para

programas que no contienen SQL incorporado.

utilemb.o

Incluye el archivo objeto del programa de utilidad de SQL incorporado para los

programas de SQL incorporado.


-L$DB2PATH/$LIB









v “Opciones de compilación y enlace para rutinas C++ de AIX” en la página 374


v “bldapp -- Builds AIX C++ applications (C++)”

Opciones de compilación y enlace para aplicaciones C de HP-UX



el compilador C de HP-UX, tal como muestra el script de creación bldapp.




cc Indica el compilador C.

$EXTRA_CFLAG

Si la plataforma HP-UX es IA64 y está habilitado el soporte de 64 bits, este

distintivo contiene el valor +DD64; si está habilitado el soporte de 32 bits, contiene

el valor +DD32. Si la plataforma HP-UX es PA-RISC y está habilitado el soporte de

64 bits, contiene el valor +DA2.0W. Para el soporte de 32 bits en una plataforma

PA-RISC, este distintivo contiene el valor +DA2.0N.

+DD64 Se debe utilizar para generar código de 64 bits para HP-UX en IA64.


+DA2.0W

Se debe utilizar para generar código de 64 bits para HP-UX en PA-RISC.

+DA2.0N

Se debe utilizar para generar código de 32 bits para HP-UX en PA-RISC.-Ae Habilita la modalidad ampliada ANSI de HP.

-I$DB2PATH/include

Especifica la ubicación de los archivos de inclusión de DB2.



Opciones de enlace:

cc Hace que el compilador se utilice como interfaz del editor de enlaces.

$EXTRA_CFLAG








+DA2.0W


+DA2.0N

Se debe utilizar para generar código de 32 bits para HP-UX en PA-RISC.-o $1 Especifica el ejecutable.


utilemb.o



utilapi.o

Si es un programa de SQL no incorporado, incluir el archivo objeto del programa

de utilidad de la API de DB2 para la comprobación de errores.

$EXTRA_LFLAG

Especificar la vía de acceso de tiempo de ejecución. Si se establece, para 32 bits

contiene el valor -Wl,+b$HOME/sqllib/lib32, y para 64 bits contiene

-Wl,+b$HOME/sqllib/lib64. Si no se establece, no contiene ningún valor.

-L$DB2PATH/$LIB


DB2. Para 32 bits: $HOME/sqllib/lib32; para 64 bits: $HOME/sqllib/lib64.








v “bldapp -- Builds HP-UX C applications (C)”

Opciones de compilación y enlace para aplicaciones C++ de

HP-UX


recomienda para crear aplicaciones en C++ de SQL incorporado y de la API de

DB2 con el compilador C++ de HP-UX, tal como muestra el script de creación

bldapp.



aCC Indica el compilador aC++ de HP.

$EXTRA_CFLAG








+DA2.0W


+DA2.0N

Se debe utilizar para generar código de 32 bits para HP-UX en PA-RISC.-ext Permite el uso de diversas extensiones de C++, que incluyen el soporte para ″long

long″.

-I$DB2PATH/include


$HOME/sqllib/include




Opciones de enlace:

aCC Hace que el compilador aC++ de HP se utilice como interfaz del editor de enlaces.

$EXTRA_CFLAG








+DA2.0W


+DA2.0N

Se debe utilizar para generar código de 64 bits para HP-UX en PA-RISC.-o $1 Especifica el ejecutable.


utilemb.o



utilapi.o



$EXTRA_LFLAG


contiene el valor ″-Wl,+b$HOME/sqllib/lib32″, y para 64 bits: ″-Wl,+b$HOME/sqllib/lib64″. Si no se establece, no contiene ningún valor.

-L$DB2PATH/$LIB






v “Creación de aplicaciones y rutinas escritas en C y C++” en la página 225


v “bldapp -- Builds HP-UX C++ applications (C++)”

Opciones de compilación y enlace para aplicaciones C de Linux



el compilador C de Linux, tal como muestra el script de creación bldapp.




$CC El compilador gcc o xlc_r.

$EXTRA_C_FLAGS

Contiene uno de los siguientes valores:

v -m31 en Linux sólo para zSeries, para crear una biblioteca de 32 bits;

v -m32 en Linux para x86, x86_64 y POWER, para crear una biblioteca de 32 bits;

v -m64 en Linux para zSeries, POWER, x86_64, para crear una biblioteca de 32

bits; o

v Ningún valor en Linux para IA64, para crear una biblioteca de 64 bits.

-I$DB2PATH/include


-c Hace que se efectúe solamente la compilación, no la edición de enlaces. Este

archivo de script tiene pasos separados para la compilación y la edición de

enlaces.

Opciones de enlace:

$CC El compilador gcc o xlc_r; hace que el compilador se utilice como interfaz del

editor de enlaces.

$EXTRA_C_FLAGS





bits; o


-o $1 Especifica el ejecutable.

$1.o Especifica el archivo objeto.

utilemb.o



utilapi.o



$EXTRA_LFLAG

Para 32 bits contiene el valor ″-Wl,-rpath,$DB2PATH/lib32″, y para 64 bits

contiene el valor ″-Wl,-rpath,$DB2PATH/lib64″.

-L$DB2PATH/$LIB

Especifica la ubicación de las bibliotecas estáticas y compartidas de DB2 durante

el enlace. Por ejemplo, para 32 bits: $HOME/sqllib/lib32, y para 64 bits:

$HOME/sqllib/lib64.








v “bldapp -- Builds Linux C applications (C)”


Linux



DB2 con el compilador C++ de Linux, tal como muestra el script de creación

bldapp.



g++ Indica el compilador C++ de GNU/Linux.

$EXTRA_C_FLAGS





bits; o


-I$DB2PATH/include




enlaces.


Opciones de enlace:

g++ Hace que el compilador se utilice como interfaz del editor de enlaces.

$EXTRA_C_FLAGS





bits; o



$1.o Incluir el archivo objeto del programa.

utilemb.o



utilapi.o



$EXTRA_LFLAG

Para 32 bits contiene el valor ″-Wl,-rpath,$DB2PATH/lib32″, y para 64 bits

contiene el valor ″-Wl,-rpath,$DB2PATH/lib64″.

-L$DB2PATH/$LIB



$HOME/sqllib/lib64.






v “bldapp -- Builds Linux C++ applications (C++)”

Opciones de compilación y enlace para aplicaciones C de

Solaris



el compilador C de Forte, tal como muestra el script de creación bldapp.





-xarch=$CFLAG_ARCH

Esta opción asegura que el compilador creará ejecutables válidos cuando

establezca un enlace con libdb2.so. El valor de $CFLAG_ARCH es ″v8plusa″ para

la modalidad de 32 bits, o ″v9″ para la modalidad de 64 bits.

-I$DB2PATH/include



-c Hace que se efectúe solamente la compilación, no la edición de enlaces. Este script

tiene pasos separados para la compilación y la edición de enlaces.

Opciones de enlace:


-xarch=$CFLAG_ARCH




-mt Crea enlaces cuando se utiliza el soporte de varias hebras. Esta opción es

necesaria para enlazar con libdb2.

Nota: Si se utilizan hebras de POSIX, las aplicaciones DB2 se deben también

enlazar con -lpthread, tengan o no varias hebras.



utilemb.o



utilapi.o



-L$DB2PATH/$LIB



$HOME/sqllib/lib64.

$EXTRA_LFLAG

Especifica la ubicación de las bibliotecas compartidas de DB2 durante la ejecución.

Para 32 bits contiene el valor ″-R$DB2PATH/lib32″, y para 64 bits contiene el

valor ″-R$DB2PATH/lib64″.







v “bldapp -- Builds Solaris C applications (C)”



Solaris



DB2 con el compilador C++ de Forte, tal como muestra el script de creación

bldapp.



CC Indica el compilador C++.

-xarch=$CFLAG_ARCH




-I$DB2PATH/include





Opciones de enlace:

CC Hace que el compilador se utilice como interfaz del editor de enlaces.

-xarch=$CFLAG_ARCH




-mt Crea enlaces cuando se utiliza el soporte de varias hebras. Esta opción es

necesaria para enlazar con libdb2.

Nota: Si se utilizan hebras de POSIX, las aplicaciones DB2 se deben también

enlazar con -lpthread, tengan o no varias hebras.



utilemb.o



utilapi.o



-L$DB2PATH/$LIB



$HOME/sqllib/lib64.

$EXTRA_LFLAG









página 209


v “bldapp -- Builds Solaris C++ applications (C++)”

Opciones de compilación y enlace para aplicaciones C y C++ de

Windows

A continuación se muestran las opciones de compilación y enlace recomendadas

para DB2 para crear aplicaciones de SQL incorporado y de la API de DB2 en C y

C++ en Windows con el compilador Microsoft Visual C++, tal como se muestra en

el archivo de proceso por lotes bldapp.bat.



%BLDCOMP%

Variable del compilador. El valor por omisión es cl, que indica el compilador

Microsoft Visual C++. Puede tener también el valor icl, el compilador Intel C++

para para aplicaciones de 32 ó 64 bits, o ecl, el compilador Intel C++ para

aplicaciones Itanium de 64 bits.

-Zi Habilitar la información de depuración.

-Od Inhabilitar las optimizaciones. Es más fácil utilizar un depurador si la

optimización está inhabilitada.

-c Hace que se efectúe solamente la compilación, no la edición de enlaces. El archivo

de proceso por lotes tiene pasos separados para la compilación y la edición de

enlaces.

-W2 Emitir mensajes de aviso, de error, de error grave y de error no recuperable.

-DWIN32

Opción de compilador necesaria para los sistemas operativos Windows.

Opciones de enlace:

link Indica la utilización del enlazador para la edición de enlaces.

-debug Hace que se incluya información de depuración.

-out:%1.exe

Especifique un nombre de archivo.

%1.obj Incluir el archivo objeto.

utilemb.obj



utilapi.obj



db2api.lib

Enlazar con la biblioteca DB2.



v “Creación de aplicaciones C/C++ en Windows” en la página 227



v “bldapp.bat -- Builds C++ applications on Windows”

v “bldapp.bat -- Builds C applications on Windows”

Creación de aplicaciones y rutinas escritas en COBOL

Creación de aplicaciones y rutinas escritas en COBOL

Se proporcionan scripts de creación para distintas plataformas de sistemas

operativos con el producto para facilitar la creación de aplicaciones de SQL

incorporado en COBOL. Además de los scripts de creación utilizados para crear

aplicaciones, se proporciona un script específico, bldrtn, que sirve para crear

rutinas (procedimientos almacenados y funciones definidas por el usuario).

Cuando trabaje con aplicaciones escrita en el lenguaje Micro Focus COBOL en

Linux, asegúrese de configurar el compilador de modo que pueda acceder a ciertas

bibliotecas compartidas de COBOL. Se suministran ejemplos IBM COBOL que se

encuentran en el directorio sqllib/samples/cobol para UNIX y en el directorio

sqllib\samples\cobol para Windows; para los directorios de ejemplos de Micro

Focus COBOL, sustituya ’cobol’ al final de la vía de acceso por ’cobol_mf’.




v “Creación de aplicaciones Micro Focus COBOL en Windows” en la página 251



Creación de aplicaciones IBM COBOL en AIX

DB2 proporciona scripts de creación para compilar y enlazar programas IBM

COBOL de SQL incorporado y programas de la API de administración de DB2.

Estos scripts residen en el directorio sqllib/samples/cobol, junto con programas

de ejemplo que se pueden crear a partir de esos archivos.

El archivo de creación, bldapp, contiene los mandatos para crear un programa de

aplicación DB2.




datos, por lo que también se proporcionan otros tres parámetros opcionales: el

segundo parámetro, $2, especifica el nombre de la base de datos con la que se

desea conectar; el tercer parámetro, $3, especifica el ID de usuario correspondiente

a la base de datos, y $4 especifica la contraseña.






Procedimiento:


Para crear el programa de ejemplo de SQL no incorporado, client, a partir del

archivo fuente client.cbl, especifique:

bldapp client

El resultado es un archivo ejecutable, client. Para ejecutar el archivo ejecutable

sobre la base de datos sample, especifique:

client


A partir del archivo fuente updat.sqb, puede crear la aplicación de SQL

incorporado, updat, de tres maneras:


bldapp updat



bldapp updat basedatos



bldapp updat basedatos IDusuario contraseña

El resultado es un archivo ejecutable, updat.




updat



updat basedatos









v “Creación de rutinas IBM COBOL en AIX” en la página 396


v “Opciones de compilación y enlace para aplicaciones IBM COBOL de AIX” en la

página 259



v “client.cbl -- How to set and query a client (IBM COBOL)”

v “updat.sqb -- How to update, delete and insert table data (IBM COBOL)”

v “bldapp -- Builds AIX COBOL applications”


v “embprep -- To prep and bind a COBOL embedded SQL sample on AIX”

Creación de aplicaciones Micro Focus COBOL de UNIX

DB2 proporciona scripts de creación para compilar y enlazar programas Micro

Focus COBOL de SQL incorporado y de la API de DB2. Estos scripts residen en el

directorio sqllib/samples/cobol_mf, junto con programas de ejemplo que se


El archivo de creación, bldapp, contiene los mandatos para crear un programa de

aplicación DB2.




datos, por lo que también se proporcionan otros tres parámetros opcionales: el

segundo parámetro, $2, especifica el nombre de la base de datos con la que se

desea conectar; el tercer parámetro, $3, especifica el ID de usuario correspondiente

a la base de datos, y $4 especifica la contraseña.






Procedimiento:



bldapp client

El resultado es un archivo ejecutable, client. Para ejecutar el archivo ejecutable

sobre la base de datos sample, especifique:

client





bldapp updat












updat



updat basedatos






v “Creación de rutinas Micro Focus COBOL de UNIX” en la página 398


v “Opciones de compilación y enlace para aplicaciones Micro Focus COBOL de

AIX” en la página 260


HP-UX” en la página 261


Linux” en la página 262


Solaris” en la página 261


v “bldapp -- Builds Linux Micro Focus COBOL applications”

v “bldapp -- Builds Solaris Micro Focus COBOL applications”

v “client.cbl -- How to set and query a client (MF COBOL)”

v “updat.sqb -- How to update, delete and insert table data (MF COBOL)”

v “bldapp -- Builds AIX Micro Focus COBOL applications”

v “bldapp -- Builds HP-UX Micro Focus COBOL applications”


programs (C)”

Creación de aplicaciones IBM COBOL en Windows


de DB2 y de SQL incorporado. Estos archivos residen en el directorio

sqllib\samples\cobol, junto con programas de ejemplo que se pueden crear a

partir de esos archivos.

DB2 da soporte a dos precompiladores para crear aplicaciones IBM COBOL en

Windows, el precompilador de DB2 y el precompilador de IBM COBOL. El valor

por omisión es el precompilador de DB2. El precompilador de IBM COBOL se

puede seleccionar descomentando la línea apropiada del archivo de proceso por

lotes que se esté utilizando. La precompilación con IBM COBOL la realiza el

propio compilador, utilizando opciones de precompilación específicas.


programas de aplicación DB2. Utiliza un máximo de cuatro parámetros como

entrada, que están representados dentro del archivo de proceso por lotes por las

variables %1, %2, %3 y %4.









Para un programa de SQL incorporado que utiliza el precompilador de DB2 por

omisión, bldapp.bat pasa los parámetros al archivo de precompilación y

vinculación, embprep.bat.

Para un programa de SQL incorporado que utiliza el precompilador de IBM

COBOL, bldrtn.bat copia el archivo fuente .sqb en un archivo fuente .cbl. El

compilador realiza la precompilación sobre el archivo fuente .cbl con opciones de

precompilación específicas.

Para cualquiera de los precompiladores, si no se proporciona un nombre de base

de datos, se utiliza la base de datos por omisión sample. Los parámetros de ID de



Procedimiento:





bldapp client

El resultado es un archivo ejecutable, client.exe. Para ejecutar el archivo

ejecutable sobre la base de datos sample, especifique el nombre del ejecutable (sin

la extensión):

client





bldapp updat












updat



updat basedatos










v “Opciones de compilación y enlace para aplicaciones IBM COBOL de Windows”

en la página 263


v “bldapp.bat -- Builds Windows VisualAge COBOL applications”

v “client.cbl -- How to set and query a client (IBM COBOL)”

v “embprep.bat -- To prep and bind a COBOL embedded SQL program on

Windows”

v “updat.sqb -- How to update, delete and insert table data (IBM COBOL)”

Creación de aplicaciones Micro Focus COBOL en Windows


de DB2 y de SQL incorporado. Estos archivos residen en el directorio

sqllib\samples\cobol_mf, junto con programas de ejemplo que se pueden crear a



programas de aplicación DB2. Utiliza un máximo de cuatro parámetros como

entrada, que están representados dentro del archivo de proceso por lotes por las

variables %1, %2, %3 y %4.








Para un programa de SQL incorporado, bldapp pasa los parámetros al archivo de

precompilación y vinculación, embprep.bat. Si no se proporciona un nombre de

base de datos, se utiliza la base de datos por omisión sample. Los parámetros de

ID de usuario y contraseña sólo son necesarios si la instancia donde se crea el

programa es diferente de la instancia donde reside la base de datos.

Procedimiento:






bldapp client

El resultado es un archivo ejecutable, client.exe. Para ejecutar el archivo

ejecutable sobre la base de datos sample, especifique el nombre del ejecutable (sin

la extensión):

client





bldapp updat







El resultado es un archivo ejecutable, updat.exe.


1. Si accede a la base de datos sample en la misma instancia, especifique

simplemente el nombre del ejecutable (sin la extensión):

updat



updat basedatos











Windows” en la página 264


v “bldapp.bat -- Builds Windows Micro Focus Cobol applications”

v “client.cbl -- How to set and query a client (MF COBOL)”

v “updat.sqb -- How to update, delete and insert table data (MF COBOL)”




Configuración del compilador IBM COBOL en Windows

Si desarrolla aplicaciones que contienen SQL incorporado y llamadas a la API de

DB2 y está utilizando el compilador IBM VisualAge COBOL, hay varias

consideraciones a tener en cuenta.

Procedimiento:

v Cuando precompile la aplicación utilizando el precompilador de DB2 y use el

mandato de procesador de línea de mandatos db2 prep, utilice la opción target

ibmcob.

v No utilice caracteres de tabulación en los archivos fuente.

v Utilice las palabras clave PROCESS y CBL en los archivos fuente para definir

opciones de compilación. Coloque las palabras clave en las columnas 8 a la 72

solamente.

v Si la aplicación sólo contiene SQL incorporado y ninguna llamada a la API de

DB2, no es necesario que utilice la opción de compilación pgmname(mixed). Si

especifica llamadas a la API de DB2, debe utilizar la opción de compilación

pgmname(mixed).

v Si utiliza la opción ″System/390 host data type support″ del compilador IBM

VisualAge COBOL, los archivos de inclusión de DB2 correspondientes a las

aplicaciones se encuentran en el siguiente directorio:

%DB2PATH%\include\cobol_i

Si crea programas DB2 de ejemplo utilizando los archivos de proceso por lotes

proporcionados, la vía de acceso de los archivos de inclusión especificada en los

archivos de proceso por lotes se debe cambiar para que apunte al directorio

cobol_i y no al directorio cobol_a.

Si NO utiliza la opción ″System/390 host data type support″ del compilador

IBM VisualAge COBOL, o si utiliza una versión anterior de este compilador, los

archivos de inclusión de DB2 correspondientes a las aplicaciones se encuentran

en el siguiente directorio:

%DB2PATH%\include\cobol_a

El directorio cobol_a es el directorio por omisión.

v Especifique nombres de archivo de COPY de modo que incluyan la extensión

.cbl, de la manera siguiente:

COPY "sql.cbl".


v “Creación de aplicaciones IBM COBOL en Windows” en la página 249

v “Creación de rutinas IBM COBOL en Windows” en la página 399


v “Opciones de compilación y enlace para aplicaciones IBM COBOL de Windows”

en la página 263

v “Opciones de compilación y enlace para rutinas IBM COBOL de Windows” en la

página 395


Configuración del compilador Micro Focus COBOL en Windows


DB2, y está utilizando el compilador Micro Focus, existen varias consideraciones

para tener en cuenta.

Procedimiento:

v Cuando precompile la aplicación utilizando el mandato db2 prep del procesador

de línea de mandatos, utilice la opción target mfcob.

v Asegúrese de que la variable de entorno LIB apunta a %DB2PATH%\lib utilizando

el siguiente mandato:

set LIB="%DB2PATH%\lib;%LIB%"

v Los archivos de COPY para DB2 correspondientes a Micro Focus COBOL residen

en %DB2PATH%\include\cobol_mf. Defina la variable de entorno COBCPY para que

incluya ese directorio del siguiente modo:

set COBCPY="%DB2PATH%\include\cobol_mf;%COBCPY%"

Debe asegurarse de que las variables de entorno antes mencionadas estén

establecidas permanentemente en los valores del Sistema. Esto se puede

comprobar siguiendo estos pasos:

1. Abra el Panel de control

2. Seleccione Sistema

3. Seleccione la pestaña Avanzado

4. Pulse en Variables de entorno

5. Compruebe en la lista Variables del sistema si aparecen las variables de

entorno necesarias. Si no están, añádalas a la lista Variables del sistema

Establecerlas en los valores de Usuario, en un indicador de mandatos o en un

script no es suficiente.

Las llamadas a las API de DB2 se deben realizar utilizando el convenio de llamada

74. El precompilador DB2 COBOL inserta automáticamente una cláusula

CALL-CONVENTION en un párrafo SPECIAL-NAMES. Si el párrafo

SPECIAL-NAMES no existe, el precompilador DB2 COBOL lo crea, de esta manera:

Identification Division

Program-ID. "static".

special-names.

call-convention 74 is DB2API.

Además, el precompilador inserta automáticamente el símbolo DB2API, que sirve

para identificar el convenio de llamada, a continuación de la palabra clave ″call″

cada vez que se llama a una API de DB2. Esto ocurre, por ejemplo, cada vez que el

precompilador emite una llamada a una API de DB2 a partir de una sentencia de

SQL incorporado.

Si las llamadas a las API de DB2 se realizan en una aplicación que no está

precompilada, es necesario crear manualmente un párrafo SPECIAL-NAMES en la

aplicación, similar al proporcionado más arriba. Si llama a una API de DB2

directamente, necesitará añadir manualmente el símbolo DB2API a continuación de

la palabra clave ″call″.



v “Creación de rutinas Micro Focus COBOL en Windows” en la página 401





v “Opciones de compilación y enlace para rutinas Micro Focus COBOL de


Configuración del compilador Micro Focus COBOL en Linux

Procedimiento:

Para ejecutar rutinas de Micro Focus COBOL, el editor de enlaces de Linux debe

poder acceder a determinadas bibliotecas compartidas de Java, y DB2 debe poder

cargar estas bibliotecas. Debido a que el programa que realiza esta carga se ejecuta

con privilegios setuid, sólo buscará las bibliotecas dependientes en /usr/lib.

Cree enlaces simbólicos con /usr/lib para las bibliotecas compartidas de COBOL.

Esto se debe hacer como usuario root. La manera más sencilla de hacerlo es

enlazando todos los archivos de bibliotecas de COBOL de $COBDIR/lib con

/usr/lib:

ln -s $COBDIR/lib/libcob* /usr/lib

donde $COBDIR es el lugar en que está instalado Micro Focus COBOL, normalmente

/opt/lib/mfcobol.

Éstos son los mandatos para enlazar cada uno de los archivos individuales

(suponiendo que Micro Focus COBOL está instalado en /opt/lib/mfcobol):

ln -s /opt/lib/mfcobol/lib/libcobrts.so /usr/lib

ln -s /opt/lib/mfcobol/lib/libcobrts_t.so /usr/lib

ln -s /opt/lib/mfcobol/lib/libcobrts.so.2 /usr/lib

ln -s /opt/lib/mfcobol/lib/libcobrts_t.so.2 /usr/lib

ln -s /opt/lib/mfcobol/lib/libcobcrtn.so /usr/lib

ln -s /opt/lib/mfcobol/lib/libcobcrtn.so.2 /usr/lib

ln -s /opt/lib/mfcobol/lib/libcobmisc.so /usr/lib

ln -s /opt/lib/mfcobol/lib/libcobmisc_t.so /usr/lib

ln -s /opt/lib/mfcobol/lib/libcobmisc.so.2 /usr/lib

ln -s /opt/lib/mfcobol/lib/libcobmisc_t.so.2 /usr/lib

ln -s /opt/lib/mfcobol/lib/libcobscreen.so /usr/lib

ln -s /opt/lib/mfcobol/lib/libcobscreen.so.2 /usr/lib

ln -s /opt/lib/mfcobol/lib/libcobtrace.so /usr/lib

ln -s /opt/lib/mfcobol/lib/libcobtrace_t.so /usr/lib

ln -s /opt/lib/mfcobol/lib/libcobtrace.so.2 /usr/lib

ln -s /opt/lib/mfcobol/lib/libcobtrace_t.so.2 /usr/lib

Es necesario hacer lo siguiente en cada instancia de DB2.



v Debe incluir el directorio del archivo COPY de DB2 para COBOL en la variable

de entorno COBCOPY de Micro Focus COBOL. La variable de entorno COBCPY

especifica la ubicación de los archivos COPY. Los archivos COPY de DB2

correspondientes a Micro Focus COBOL residen en sqllib/include/cobol_mf,

dentro del directorio de la instancia de la base de datos.

Para incluir el directorio en la variable de entorno, especifique:

– En el shell bash o Korn:

export COBCPY=$HOME/sqllib/include/cobol_mf:$COBDIR/cpylib

– En el shell C:

setenv COBCPY $HOME/sqllib/include/cobol_mf:$COBDIR/cpylib


v Actualizar la variable de entorno:


export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$HOME/sqllib/lib:$COBDIR/lib

– En el shell C:

setenv LD_LIBRARY_PATH $LD_LIBRARY_PATH:$HOME/sqllib/lib:$COBDIR/lib

v Establecer la Lista de entornos de DB2:

db2set DB2ENVLIST="COBDIR LD_LIBRARY_PATH"

Nota: Es posible que desee establecer COBCPY, COBDIR y LD_LIBRARY_PATH en

.bashrc, .kshrc (según el shell que se utilice), .bash_profile, .profile

(según el shell que se utilice) o en .login. .






Linux” en la página 262

v “Opciones de compilación y enlace para rutinas Micro Focus COBOL de Linux”

en la página 394

Configuración del compilador IBM COBOL en AIX

Debe seguir los pasos siguientes si desarrolla aplicaciones que contienen SQL

incorporado y llamadas a la API de DB2, y está utilizando el compilador IBM

COBOL Set para AIX.

Procedimiento:

v Cuando precompile la aplicación utilizando el mandato de procesador de línea

de mandatos db2 prep, utilice la opción target ibmcob.

v No utilice caracteres de tabulación en los archivos fuente.

v Puede utilizar las palabras clave PROCESS y CBL en la primera línea de los

archivos fuente para definir opciones de compilación.

v Si la aplicación sólo contiene SQL incorporado y ninguna llamada a la API de

DB2, no es necesario que utilice la opción de compilación pgmname(mixed). Si

especifica llamadas a la API de DB2, debe utilizar la opción de compilación

pgmname(mixed).

v Si utiliza la opción ″System/390 host data type support″ del compilador IBM

COBOL Set para AIX, los archivos de inclusión de DB2 correspondientes a las

aplicaciones están contenidos en este directorio:

$HOME/sqllib/include/cobol_i

Si crea programas DB2 de ejemplo utilizando los archivos de script

proporcionados, la vía de acceso de los archivos de inclusión especificada en los

archivos de script se debe cambiar para que apunte al directorio cobol_i y no al

directorio cobol_a.

Si NO utiliza la opción ″System/390 host data type support″ del compilador

IBM COBOL Set para AIX, o está utilizando una versión anterior de este

compilador, los archivos de inclusión de DB2 correspondientes a las aplicaciones

están contenidos en este directorio:

$HOME/sqllib/include/cobol_a


Especifique nombres de archivo de COPY de modo que incluyan la extensión

.cbl, de la manera siguiente:

COPY "sql.cbl".


v “Consideraciones sobre la instalación de COBOL en AIX” en Desarrollo de SQL y

rutinas externas






página 259

v “Opciones de compilación y enlace para rutinas IBM COBOL de AIX” en la

página 391

Configuración del compilador Micro Focus COBOL en AIX

Siga los pasos siguientes si desarrolla aplicaciones que contienen SQL incorporado

y llamadas a la API de DB2 y utiliza el compilador Micro Focus COBOL.

Procedimiento:










export COBCPY=$COBCPY:$HOME/sqllib/include/cobol_mf

– En el shell C:

setenv COBCPY $COBCPY:$HOME/sqllib/include/cobol_mf

Nota: Puede definir COBCPY dentro del archivo .profile o .login.


v “Consideraciones sobre la instalación de COBOL en AIX” en Desarrollo de SQL y

rutinas externas







v “Opciones de compilación y enlace para rutinas Micro Focus COBOL de AIX” en

la página 392


Configuración del compilador Micro Focus COBOL en HP-UX


DB2, y está utilizando el compilador Micro Focus COBOL, existen varias

consideraciones para tener en cuenta.

Procedimiento:








Para incluir el directorio en la variable de entorno,

– en el shell bash o Korn, especifique:


– en el shell C, especifique:

setenv COBCPY ${COBCPY}:${HOME}/sqllib/include/cobol_mf

Nota: Puede definir COBCPY dentro del archivo .profile o .login.






HP-UX” en la página 261

v “Opciones de compilación y enlace para rutinas Micro Focus COBOL de HP-UX”

en la página 393

Configuración del compilador Micro Focus COBOL en Solaris


DB2, y está utilizando el compilador Micro Focus COBOL, debe tener en cuenta

varias consideraciones.

Procedimiento:











– En el shell C:

setenv COBCPY $COBCPY:$HOME/sqllib/include/cobol_mf


Nota: Puede definir COBCPY dentro del archivo .profile.






Solaris” en la página 261

v “Opciones de compilación y enlace para rutinas Micro Focus COBOL de Solaris”

en la página 393

Opciones de compilación y enlace para aplicaciones IBM COBOL

de AIX


para DB2 para crear aplicaciones de SQL incorporado y de la API de DB2 en

COBOL con el compilador IBM COBOL para AIX, tal como se muestra en el script

de creación bldapp.



cob2 El compilador IBM COBOL para AIX.

-qpgmname$mixed$

Indica al compilador que permita llamadas a los puntos de entrada de biblioteca

utilizando nombres con mayúsculas y minúsculas mezcladas.

-qlib Indica al compilador que procese las sentencias COPY.

-I$DB2PATH/include/cobol_a


$HOME/sqllib/include/cobol_a.



Opciones de enlace:

cob2 Hace que el compilador se utilice como interfaz del editor de enlaces.



checkerr.o

Hace que se incluya el archivo objeto de programa de utilidad para la

comprobación de errores.

-L$DB2PATH/$LIB


DB2. Por ejemplo: $HOME/sqllib/lib32.

-ldb2 Enlazar con la biblioteca del gestor de bases de datos.




v “Configuración del compilador IBM COBOL en AIX” en la página 256




página 391


v “bldapp -- Builds AIX COBOL applications”

Opciones de compilación y enlace para aplicaciones Micro

Focus COBOL de AIX



DB2 en COBOL con el compilador Micro Focus COBOL en AIX, tal como se

muestra en el script de creación bldapp. Tenga en cuenta que los archivos de

inclusión de DB2 MicroFocus COBOL se localizan configurando la variable de

entorno COBCPY, de modo que no se necesita el distintivo -I en el paso de

compilación. Consulte el script bldapp para ver un ejemplo.



cob El compilador MicroFocus COBOL.

-c Hace que se efectúe solamente la compilación, no la edición de enlaces.

$EXTRA_COBOL_FLAG="-C MFSYNC"

Habilita el soporte de 64 bits.

-x Cuando se utiliza con -c, crea un archivo objeto.

Opciones de enlace:

cob Hace que el compilador se utilice como interfaz del editor de enlaces.

-x Crea un programa ejecutable.



-L$DB2PATH/$LIB




-ldb2gmf

Establece un enlace con la biblioteca del gestor de excepciones de DB2

correspondiente a Micros Focus COBOL.




v “Configuración del compilador Micro Focus COBOL en AIX” en la página 257



la página 392



v “bldapp -- Builds AIX Micro Focus COBOL applications”


Focus COBOL de HP-UX



DB2 en COBOL con el compilador Micro Focus COBOL en HP-UX, tal como se

muestra en el script de creación bldapp.



cob Indica el compilador Micro Focus COBOL.

-cx Compila para crear el módulo objeto.

$EXTRA_COBOL_FLAG

Contiene ″-C MFSYNC″ si la plataforma HP-UX es IA64 y el soporte de 64 bits

está habilitado.

Opciones de enlace:


-x Especifica un programa ejecutable.


checkerr.o

Incluir el archivo objeto del programa de utilidad para la comprobación de

errores.

-L$DB2PATH/$LIB


DB2.


-ldb2gmf






v “Configuración del compilador Micro Focus COBOL en HP-UX” en la página

258


v “bldapp -- Builds HP-UX Micro Focus COBOL applications”


Focus COBOL de Solaris



DB2 en COBOL con el compilador Micro Focus COBOL en Solaris, tal como se






$EXTRA_COBOL_FLAG

Para soporte de 64 bits, contiene el valor ″-C MFSYNC″; de lo contrario, no

contiene ningún valor.


Opciones de enlace:




checkerr.o



-L$DB2PATH/$LIB


el enlace. Por ejemplo: $HOME/sqllib/lib64.


-ldb2gmf






v “Configuración del compilador Micro Focus COBOL en Solaris” en la página 258


v “bldapp -- Builds Solaris Micro Focus COBOL applications”


Focus COBOL de Linux



DB2 en COBOL con el compilador Micro Focus COBOL en Linux, tal como se





-cx Compila y crea el módulo objeto.

$EXTRA_COBOL_FLAG

Para el soporte de 64 bits, contiene el valor ″-C MFSYNC″; de lo contrario, no



Opciones de enlace:



-o $1 Incluir el ejecutable.


checkerr.o

Incluir el archivo objeto del programa de utilidad para la comprobación de

errores.

-L$DB2PATH/$LIB


DB2.


-ldb2gmf





v “Configuración del compilador Micro Focus COBOL en Linux” en la página 255



v “bldapp -- Builds Linux Micro Focus COBOL applications”


programs (C)”

Opciones de compilación y enlace para aplicaciones IBM COBOL

de Windows



COBOL en Windows con el compilador IBM VisualAge COBOL, tal como se

muestra en el archivo de proceso por lotes bldapp.bat.




cob2 El compilador IBM VisualAge COBOL.

-qpgmname(mixed)






-Ivía Especifica la ubicación de los archivos de inclusión de DB2. Por ejemplo:

-I"%DB2PATH%\include\cobol_a".

%EXTRA_COMPFLAG%

Si ″set IBMCOB_PRECOMP=true" no tiene comentarios, el precompilador IBM COBOL

se utilizará para precompilar el SQL incorporado. Se invocará con una de las

siguientes formulaciones, en función de los parámetros de entrada:

-q"SQL(’database sample CALL_RESOLUTION DEFERRED’)"

precompilar utilizando la base de datos de ejemplo por omisión, y diferir

la resolución de la llamada.

-q"SQL(’database %2 CALL_RESOLUTION DEFERRED’)"

precompilar utilizando una base de datos especificada por el usuario, y

diferir la resolución de la llamada.

-q"SQL(’database %2 user %3 using %4 CALL_RESOLUTION DEFERRED’)"

precompilar utilizando una base de datos, un ID de usuario y una

contraseña especificados por el usuario, y diferir la resolución de la

llamada. Éste es el formato para el acceso de clientes remotos.

Opciones de enlace:

cob2 Utilizar el compilador como interfaz del editor de enlaces.

%1.obj Incluir el archivo objeto del programa.

checkerr.obj

Incluir el archivo objeto del programa de utilidad de comprobación de errores.

db2api.lib

Enlazar con la biblioteca de DB2.



v “Creación de aplicaciones IBM COBOL en Windows” en la página 249

v “Configuración del compilador IBM COBOL en Windows” en la página 253


v “bldapp.bat -- Builds Windows VisualAge COBOL applications”


Focus COBOL de Windows



COBOL en Windows con el compilador Micro Focus COBOL, tal como se muestra

en el archivo de proceso por lotes bldapp.bat.



Opción de compilación:

cobol Indica el compilador Micro Focus COBOL.

Opciones de enlace:

cbllink

Utilizar el enlazador para la edición de enlaces.

-l Enlazar con la biblioteca lcobol.

checkerr.obj

Enlazar con el archivo objeto del programa de utilidad de comprobación de

errores.

db2api.lib

Enlazar con la biblioteca DB2 de la API




v “Configuración del compilador Micro Focus COBOL en Windows” en la página

254


v “bldapp.bat -- Builds Windows Micro Focus Cobol applications”


escritas en REXX


escritas en REXX

Las aplicaciones REXX no se precompilan, compilan ni enlazan. Las instrucciones

siguientes describen cómo crear y ejecutar aplicaciones REXX en sistemas

operativos Windows y en el sistema operativo AIX.

Restricciones:

En plataformas basadas en Windows, el archivo de aplicación debe tener una

extensión .CMD. Después de su creación, puede ejecutar la aplicación directamente

desde el indicador de mandatos del sistema operativo. En AIX, el archivo de la

aplicación puede tener cualquier extensión.

Procedimiento:

Cree y ejecute las aplicaciones REXX del siguiente modo:

v En sistemas operativos Windows, el archivo de aplicación puede tener cualquier

nombre. Después de su creación, puede ejecutar la aplicación desde el indicador

de mandatos del sistema operativo invocando al intérprete de REXX del modo

siguiente:

REXX file_name

v En AIX, puede ejecutar la aplicación mediante cualquiera de los dos métodos

siguientes:


– En el indicador de mandatos de shell, escriba rexx name donde name es el

nombre del programa REXX.

– Si la primera línea del programa REXX contiene un ″número mágico″ (#!) e

identifica el directorio en que reside el intérprete de REXX/6000, puede

ejecutar el programa REXX escribiendo su nombre en el indicador de

mandatos del shell. Por ejemplo, si el archivo del intérprete de REXX/6000

está en el directorio /usr/bin, incluya la información siguiente como primera

línea del programa REXX:

#! /usr/bin/rexx

A continuación, haga que el programa sea ejecutable escribiendo el mandato

siguiente en el indicador de mandatos del shell:

chmod +x name

Ejecute el programa REXX escribiendo su nombre de archivo en el indicador

de mandatos del shell.

Nota: En AIX, debe establecer la variable de entorno LIBPATH para incluir el

directorio en que está ubicada la biblioteca de SQL para REXX, db2rexx.

Por ejemplo:

export LIBPATH=/lib:/usr/lib:/$DB2PATH/lib




v “Archivos de vinculación de REXX” en la página 266


Archivos de vinculación de REXX

Se proporcionan cinco archivos de vinculación para el soporte de aplicaciones

REXX. Los nombres de estos archivos están incluidos en el archivo

DB2UBIND.LST. Cada archivo de vinculación se ha precompilado utilizando un

nivel de aislamiento distinto; por consiguiente, en la base de datos hay cinco

paquetes diferentes almacenados.

Los cinco archivos de vinculación son:

DB2ARXCS.BND

Soporta el nivel de aislamiento de estabilidad del cursor.

DB2ARXRR.BND

Soporta el nivel de aislamiento de lectura repetitiva.

DB2ARXUR.BND

Soporta el nivel de aislamiento de estabilidad de lectura no confirmada.

DB2ARXRS.BND

Soporta el nivel de aislamiento de estabilidad de lectura.

DB2ARXNC.BND

Soporta el nivel de aislamiento de sin confirmación. Se utiliza este nivel de

aislamiento cuando se trabaja con algunos servidores de bases de datos de

sistema principal, AS/400 o iSeries. En otras bases de datos, se comporta

como el nivel de aislamiento de lectura no confirmada.

Nota: En algunos casos, puede que sea necesario vincular de forma explícita estos

archivos a la base de datos.


Cuando se utiliza la rutina SQLEXEC se usa, por omisión, el paquete creado con

estabilidad del cursor. Si necesita uno de los otros niveles de aislamiento, lo puede

cambiar mediante la API SQLDBS CHANGE SQL ISOLATION LEVEL antes de

conectar con la base de datos. Esto ocasionará que las posteriores llamadas a la

rutina SQLEXEC se asocien al nivel de aislamiento especificado.

Las aplicaciones REXX basadas en Windows no pueden asumir que esté en vigor el

nivel de aislamiento por omisión a menos que sepan que ningún otro programa

REXX de la sesión ha cambiado el valor. Antes de conectar con una base de datos,

una aplicación REXX debe establecer explícitamente el nivel de aislamiento.





página 58

Creación de aplicaciones Object REXX en Windows

Object REXX es un versión del lenguaje REXX orientada a objetos. Se han añadido

extensiones orientadas a objetos al REXX estándar, pero no se han modificado sus

funciones e instrucciones existentes. El programa intérprete de Object REXX es una

versión mejorada de su predecesor, e incluye soporte adicional para:

v Clases, objetos y métodos

v Gestión de mensajes y polimorfismo

v Herencia simple y múltiple

Object REXX es totalmente compatible con el REXX estándar. En esta sección,

siempre que se utiliza el término REXX se hace referencia a todas las versiones de

REXX, incluido Object REXX.

No es necesario precompilar ni enlazar los programas REXX.

En Windows, no es necesario que los programas REXX comiencen con un

comentario. Sin embargo, por razones de portabilidad, es recomendable que en

cada programa REXX coloque un comentario que comience en la primera columna

de la primera línea. Esto permitirá diferenciar el programa respecto de un mandato

de proceso por lotes cuando se ejecute en otras plataformas:

/* Coloque aquí un comentario cualquiera. */

Los programas REXX de ejemplo están contenidos en el directorio

sqllib\samples\rexx.

Procedimiento:

Para ejecutar el programa REXX de ejemplo updat, especifique:

rexx updat.cmd


v “Restricciones en el uso de REXX para programar aplicaciones de SQL





Creación de aplicaciones de SQL incorporado desde la línea de

mandatos

Creación de aplicaciones de SQL incorporado desde la línea

de mandatos

Para crear de aplicaciones de SQL incorporado desde la línea de mandatos incluye,

siga estos pasos:

1. Precompile la aplicación emitiendo el mandato PRECOMPILE

2. Si ha creado un archivo de vinculación, vincule dicho archivo a una base de

datos para crear un paquete de aplicación emitiendo el mandato BIND.

3. Compile la fuente de la aplicación modificada y los archivos fuente que no

contienen SQL incorporado para crear un archivo de objeto de aplicación (un

archivo .obj).

4. Enlace los archivos de objeto de aplicación con DB2 y con bibliotecas del

lenguaje principal para crear un programa ejecutable mediante el mandato link.




página 210

Creación de aplicaciones de SQL incorporado escritas en C o

C++ (Windows)

Después de escribir el archivo fuente, tiene que crear la aplicación de SQL

incorporado. Algunos pasos del proceso de creación dependen del compilador que

utilice. Los ejemplos que se proporcionan con casa paso del procedimiento

muestran cómo crear una aplicación denominada myapp con un compilador

Microsoft Visual Studio 6.0, que es un compilador de C. Puede ejecutar cada uno

de los pasos del procedimiento de forma individual o puede ejecutar los pasos

juntos dentro de un archivo de proceso por lotes desde un indicador de la ventana

de mandatos de DB2. Para ver un ejemplo de un archivo de proceso por lotes que

se puede utilizar para crear aplicaciones de ejemplo de SQL incorporado en el

directorio %DB2PATH%\SQLLIB\samples\c\, consulte el archivo

%DB2PATH%\SQLLIB\samples\c\bldapp.bat. Este archivo de proceso por lotes

llama a otro archivo de proceso por lotes, %DB2PATH%\SQLLIB\samples\c\embprep.bat, para precompilar la aplicación y vincular la aplicación a una base de

datos.

Requisitos previos:

v Una conexión de base de datos activa

v Un archivo de código fuente de aplicación con la extensión .sqc en C o .sqx en

C++ y que contenga SQL incorporado

v Un compilador de C o C++ soportado

v Las autorizaciones o privilegios necesarios para ejecutar el mandato

PRECOMPILE y el mandato BIND

Procedimiento:

1. Precompile la aplicación emitiendo el mandato PRECOMPILE. Por ejemplo:


Aplicación C: db2 PRECOMPILE myapp.sqc BINDFILE

Aplicación C++: db2 PRECOMPILE myapp.sqx BINDFILE

El mandato PRECOMPILE genera un archivo .c o .C, que contiene un formato

modificado del código fuente en un archivo .sqc o .sqC, un paquete de

aplicación. Si utiliza la opción BINDFILE, el mandato PRECOMPILE genera un

archivo de vinculación. En el ejemplo anterior, el archivo de vinculación se

llamaría myapp.bnd.

2. Si ha creado un archivo de vinculación, vincule dicho archivo a una base de

datos para crear un paquete de aplicación emitiendo el mandato BIND. Por

ejemplo:

db2 bind myapp.bnd

El mandato BIND asocia el paquete de aplicación a la base de datos y almacena

el paquete dentro de la misma.

3. Compile la fuente de la aplicación modificada y los archivos fuente que no

contienen SQL incorporado para crear un archivo de objeto de aplicación (un

archivo .obj). Por ejemplo:

Aplicación C: cl -Zi -Od -c -W2 -DWIN32 myapp.c

Aplicación C++: cl -Zi -Od -c -W2 -DWIN32 myapp.cxx

4. Enlace los archivos de objeto de aplicación con DB2 y con bibliotecas del

lenguaje principal para crear un programa ejecutable mediante el mandato link.

Por ejemplo:

link -debug -out:myapp.exe myapp.obj

Siguiente tarea:

A continuación puede realizar cualquiera de las siguientes tareas:

v Depuración de errores en tiempo de compilación de la aplicación de SQL

incorporado

v Ajuste del rendimiento de aplicaciones de SQL incorporado

v Despliegue de la aplicación ejecutable, myapp.exe

v Ejecución de aplicaciones de SQL incorporado



página 58





la página 245

Migración de las aplicaciones de SQL incorporado

Para asegurarse de que las aplicaciones de SQL incorporado construidas para DB2

UDB Versión 8 funcionarán con DB2 Versión 9, tendrá que migrar dichas

aplicaciones.

Prerrequisitos:

Antes de migrar las aplicaciones de SQL incorporado, tenga en cuenta estos

puntos:


v El cliente o el servidor DB2 desde el que se ejecuta la aplicación se tiene que

migrar a DB2 Versión 9.

v Asegúrese de que el software de desarrollo que utiliza para las aplicaciones de

SQL incorporado está soportado en DB2 Versión 9.

Procedimiento:

Para migrar la aplicación de SQL incorporado de manera que funcione con DB2

Versión 9, siga estos pasos:

1. Someta a prueba las aplicaciones de SQL incorporado en un entorno de prueba

DB2 Versión 9. Si la prueba es satisfactoria, no hace falta que realice pasos

adicionales.

2. Determine si en las aplicaciones de SQL incorporado hay sentencias SQL que

hagan referencia a vistas de catálogo, rutinas SQL administrativas o vistas SQL

administrativas. Si tiene sentencias SQL que hagan referencia a estos objetos,

sométalos a prueba desde el procesador de línea de mandatos (CLP) de DB2

para asegurarse de que la vista o la rutina sigue teniendo la misma signatura.

Si es necesario, vea la documentación de consulta sobre las vistas de catálogo o

las rutinas y vistas SQL administrativas para obtener signaturas actualizadas.

3. Reconstruya las aplicaciones de SQL incorporado que hayan cambiado,

utilizando el archivo de construcción pertinente de DB2 y especificando la vía

de acceso de biblioteca compartida adecuada de DB2. En el caso de las

aplicaciones de 32 bits, especifique que la vía de acceso de biblioteca

compartida es $INSTHOME/sqllib/lib32, y en el caso de las aplicaciones de 64

bits, especifique que la vía de acceso de biblioteca compartida es

$INSTHOME/sqllib/lib64, siendo INSTHOME el directorio inicial de la instancia.

4. En el caso de las aplicaciones de SQL incorporado en UNIX y Linux, ejecute el

mandato db2chglibpath para asegurarse de que se pueden localizar todas las

bibliotecas que tengan vías de acceso cambiadas entre las versiones de DB2.

5. Opcional: valide explícitamente los paquetes asociados a las aplicaciones de

SQL incorporado: Volver a enlazar los paquetes en las bases de datos migradas.

Durante la migración de la base de datos, los paquetes existentes de las

aplicaciones de SQL incorporado quedan invalidados. Después del proceso de

migración, cada paquete se reconstruye automáticamente cuando el gestor de

bases de datos DB2 lo utiliza por primera vez.

6. Someta a prueba las aplicaciones de bases de datos para asegurarse de que

funcionan como cabe esperar bajo DB2 Versión 9.


v “Rutinas y vistas administrativas de SQL” en Vistas y rutinas de administración de

SQL


v “Revinculación de paquetes en bases de datos migradas” en Guía de migración

v “Migración de aplicaciones de bases de datos de 32 bits para ejecutarlas en

instancias de 64 bits” en Guía de migración

v “Migración de aplicaciones de bases de datos” en Guía de migración


v “Software de desarrollo soportado para aplicaciones de SQL incorporado” en la

página 12

v “Vistas de catálogo del sistema” en Consulta de SQL, Volumen 1


Restricciones de enlazar a libdb2.so

En algunas distribuciones de Linux, el rpm de desarrollo de libc viene con la

biblioteca

/usr/lib/libdb2.so

o

/usr/lib64/libdb2.so

. Esta biblioteca se utiliza para la implementación Berkeley DB de Sleepycat

Software y no está asociada con sistemas de base de datos IBM DB2.

Si no tiene pensado utilizar Berkeley DB, puede redenominar o suprimir estos

archivos de biblioteca permanentemente en los sistemas.

Si desea utilizar Berkeley DB, puede redenominar la carpeta que contiene estos

archivos de biblioteca y modificar la variable de entorno para que señale a la

nueva carpeta.




Parte 2. Desarrollo de rutinas incorporadas


Capítulo 5. Desarrollo de rutinas externas

Rutinas externas

Las rutinas externas son rutinas cuya lógica está implementada en una aplicación

de lenguaje de programación que reside fuera de la base de datos, en el sistema de

archivos del servidor de bases de datos. La asociación de la rutina con la aplicación

de código externo está indicada mediante la especificación de la cláusula

EXTERNAL en la sentencia CREATE de la rutina.

Puede crear procedimientos externos, funciones externas y métodos externos.

Aunque todos ellos se implementan en lenguajes de programación externos, cada

tipo funcional de rutina tiene características distintas. Antes de decidir la

implementación de una rutina externa, es importante que primero comprenda qué

son las rutinas externas, cómo se implementan y se utilizan leyendo el tema

″Visión general de las rutinas externas″. Una vez comprenda esto, podrá obtener

más información acerca de las rutinas externas en los temas de los enlaces

relacionados para tomar decisiones informadas sobre cuándo y cómo utilizarlas en

el entorno de bases de datos.


v “Funciones de tabla de OLE DB definidas por el usuario” en Desarrollo de SQL y

rutinas externas

v “Visión general de las rutinas externas” en la página 276

v “Visión general de las rutinas” en Desarrollo de SQL y rutinas externas

v “Soporte para el desarrollo de rutinas externas en lenguajes CLR de .NET” en


v “Soporte para el desarrollo de rutinas externas en C” en la página 315

v “Soporte para el desarrollo de rutinas externas en C++” en la página 315

v “Software soportado de desarrollo de rutinas Java” en Desarrollo de SQL y rutinas

externas

v “Rutinas CLR (common language runtime) de .NET” en Desarrollo de SQL y

rutinas externas

v “Procedimientos COBOL” en la página 388

v “Rutinas DB2GENERAL” en Desarrollo de SQL y rutinas externas

v “Funciones de rutinas externas” en la página 276

v “Rutinas Java” en Desarrollo de SQL y rutinas externas

v “Diseño de rutinas de automatización de OLE” en Desarrollo de SQL y rutinas

externas


v “Creación de rutinas C y C++” en la página 360

v “Creación de rutinas externas” en la página 312

v “Desarrollo de rutinas” en Desarrollo de SQL y rutinas externas


v “Soporte para el desarrollo de procedimientos externos en COBOL” en la página

390


v “Sentencia CREATE FUNCTION (Tabla externa)” en Consulta de SQL, Volumen 2

v “Sentencia CREATE PROCEDURE (Externo)” en Consulta de SQL, Volumen 2

Visión general de las rutinas externas

Visión general de las rutinas externas

Las rutinas externas se caracterizan principalmente por el hecho de que su lógica

de rutina se implementa en código de lenguaje de programación y no en SQL.

Antes de decidir la implementación de una rutina externa, es importante que

comprenda qué son las rutinas externas, cómo se implementan y cómo pueden

utilizarse. Los temas sobre los conceptos siguientes lo ayudarán a comprender las

rutinas externas para poder tomar decisiones informadas sobre cuándo y cómo

utilizarlas en el entorno de bases de datos:

v “Funciones de rutinas externas”

v Creación de rutinas externas

v Gestión de bibliotecas o clases de rutinas externas

v Lenguajes de programación soportados para el desarrollo de rutinas externas

v Soporte de 32 y 64 bits para rutinas externas

v Estilos de parámetros para rutinas externas

v Restricciones en las rutinas externas

Cuando haya comprendido los conceptos sobre rutinas externas, puede comenzar

a:



v “Soporte de 32 bits y 64 bits para rutinas externas” en la página 306

v “Características de las funciones y métodos externos” en la página 277



v “Gestión de bibliotecas y clases de rutinas externas” en la página 301

v “Estilos de parámetros de rutinas externas” en la página 298

v “Rutinas externas” en la página 275

v “Rendimiento de las rutinas con bibliotecas de 32 bits en servidores de bases de

datos de 64 bits” en la página 307

v “Restricciones de las rutinas externas” en la página 309

v “Interfaces API y lenguajes de programación soportados para el desarrollo de

rutinas externas” en la página 290

v “Soporte para el tipo de datos XML en las rutinas externas” en la página 308



Funciones de rutinas externas

Las rutinas externas proporcionan soporte para las funciones más comunes de

rutinas, así como soporte para funciones adicionales no soportadas por rutinas

SQL. Las siguientes funciones son exclusivas de las rutinas externas:


Acceso a archivos, datos y aplicaciones que residen fuera de la base de datos

Las rutinas externas pueden acceder y manipular datos o archivos que

residan fuera de la propia base de datos. También pueden invocar

aplicaciones que residan fuera de la base de datos. Los datos, archivos o

aplicaciones podrían residir, por ejemplo, en el sistema de archivos del

servidor de base de datos o en la red disponible.

Variedad de opciones de estilos de parámetros de rutinas externas

La implementación de rutinas externas en un lenguaje de programación se

puede realizar utilizando varias opciones de estilos de parámetros. Aunque

puede haber un estilo de parámetro preferido para un determinado

lenguaje de programación, a veces es posible escoger. Algunos estilos de

parámetros proporcionan soporte para pasar información adicional sobre

propiedades de rutinas y de bases de datos a la rutina y de recibirla de

esta en una estructura denominada estructura dbinfo que puede resultar útil

dentro de la lógica de la rutina.

Conservación de estado entre invocaciones de funciones externas con un área

reutilizable

Las funciones externas definidas por el usuario proporcionan soporte para

la conservación de estado entre invocaciones de función para un conjunto

de valores. Esto se realiza con una estructura denominada scratchpad. Esto

puede resultar útil tanto para las funciones que devuelven valores

agregados como para las funciones que necesitan lógica de configuración

inicial, como inicialización de almacenamientos intermedios.

Los tipos de llamada identifican invocaciones de funciones externas

individuales

Las funciones externas definidas por el usuario se invocan varias veces

para un conjunto de valores. Cada invocación se identifica con un valor de

tipo de llamada al que se puede hacer referencia dentro de la lógica de la

función. Por ejemplo, hay tipos de llamada especiales para la primera

invocación de una función, para las llamadas de captación de datos y para

la invocación final. Los tipos de llamada resultan útiles porque se puede

asociar lógica específica a un tipo de llamada determinado.


v “Soporte de 32 bits y 64 bits para rutinas externas” en la página 306



v “Características de procedimientos de SQL” en Desarrollo de SQL y rutinas

externas



v “SQL en rutinas externas” en Desarrollo de SQL y rutinas externas


Características de las funciones y métodos externos

Características de las funciones y métodos externos

Las funciones externas y los métodos externos proporcionan soporte para

funciones que, en el caso de un determinado conjunto de datos de entrada, se

podrían invocar múltiples veces y producir un conjunto de valores de salida.

Capítulo 5. Desarrollo de rutinas externas 277

Para obtener más información sobre las características de las funciones y métodos

externos, consulte estos temas:

v “Funciones escalares externas”

v “Modelo de proceso de los métodos y las funciones escalares externas” en la

página 280

v “Funciones de tablas externas” en la página 281

v “Modelo de proceso para las funciones de tablas externas” en la página 282

v “Modelo de ejecución de funciones de tabla para Java” en la página 284

v “Áreas reutilizables para funciones externas y métodos” en la página 285

v “Áreas reutilizables en sistemas operativos de 32 bits y 64 bits” en la página 289

Estas características son exclusivas para las funciones y métodos externos y no

atañen a las funciones SQL ni a los métodos SQL.




v “Funciones escalares externas” en la página 278




página 280

Funciones escalares externas

Las funciones escalares externas tienen implementada su lógica en un lenguaje de

programación externo.

Estas funciones pueden desarrollarse y utilizarse para ampliar el conjunto de

funciones de SQL existentes y pueden invocarse del mismo modo que las

funciones incorporadas de DB2, como por ejemplo, LENGTH y COUNT. Es decir,

se puede hacer referencia a ellas en sentencias de SQL siempre que la expresión sea

válida.

La ejecución de funciones escalares externas se lleva a cabo en el servidor de bases

de datos, aunque, a diferencia de las funciones escalares de SQL incorporadas o

definidas por el usuario, la lógica de las funciones externas puede acceder al

sistema de archivos del servidor de bases de datos, realizar llamadas al sistema o

acceder a una red.

Las funciones escalares externas pueden leer datos de SQL, pero no pueden

modificarlos.

Las funciones escalares externas se pueden invocar repetidamente para una sola

referencia de la función y pueden mantener el estado entre estas invocaciones

mediante un área reutilizable, que es un almacenamiento intermedio de memoria.

Esto puede resultar potente si una función requiere una lógica de configuración

inicial, pero costosa. La lógica de configuración se puede realizar en una primera

invocación, utilizando el área reutilizable para almacenar algunos valores, cuyo

acceso o actualización es posible en invocaciones siguientes de la función escalar.

Características de las funciones escalares externas

v Se puede hacer referencia a ellas como parte de una sentencia de SQL en

cualquier parte en que esté soportada una expresión.


v La sentencia de SQL que realiza la invocación puede utilizar

directamente la salida de una función escalar.

v Para las funciones escalares externas definidas por el usuario, se puede

mantener el estado entre las invocaciones iterativas de la función

empleando un área reutilizable.

v Pueden proporcionar una ventaja para el rendimiento cuando se utilizan

en predicados, puesto que se ejecutan en el servidor. Si una función se

puede aplicar a una fila candidata en el servidor, puede, a menudo,

dejar de tomar en consideración la fila antes de transmitirla a la

máquina cliente, con lo que se reduce la cantidad de datos que se deben

pasar desde el servidor al cliente.

Limitaciones

v No se puede realizar la gestión dentro de una función escalar. Es decir,

no se puede emitir COMMIT ni ROLLBACK dentro de una function

escalar.

v No pueden devolver conjuntos de resultados.

v Las funciones escalares están pensadas para devolver un solo valor

escalar por cada conjunto de valores de entrada.

v Las funciones escalares externas no están pensadas para que se utilicen

en una sola invocación. Están diseñadas de forma que, para cada

referencia a la función y cada conjunto determinado de valores de

entrada, la función se invoque una vez por cada valor de entrada y

devuelva un solo valor escalar. En la primera invocación, las funciones

escalares pueden estar diseñadas para realizar algún trabajo de

configuración o para almacenar información, cuyo acceso sea posible en

invocaciones posteriores. Las funciones escalares de SQL se ajustan

mejor a la funcionalidad que requiere una sola invocación.

v En una base de datos de una sola partición, las funciones escalares

externas pueden incluir sentencias de SQL. Estas sentencias pueden leer

datos de tablas, pero no pueden modificarlos. Si la base de datos tiene

más de una partición, no debe haber sentencias de SQL en una función

escalar externa. Las funciones escalares de SQL pueden contener

sentencias de SQL que lean o modifiquen datos .

Usos frecuentes

v Ampliar el conjunto de funciones incorporadas de DB2.

v Realizar operaciones lógicas dentro de una sentencia de SQL que SQL no

puede realizar de forma nativa.

v Encapsular una consulta escalar que se reutilice habitualmente como

subconsulta en las sentencias de SQL. Por ejemplo, dado un código

postal, buscar en una tabla la ciudad en la que se encuentra el código

postal.

Lenguajes soportados

v C

v C++

v Java

v OLE

v Lenguajes de ejecución en el lenguaje común .NET

Notas:

1. Existe una capacidad limitada para crear funciones de agregación. Conocidas

también como funciones de columna, estas funciones reciben un conjunto de


valores semejantes (una columna de datos) y devuelven una sola respuesta.

Una función de agregación definida por el usuario sólo se puede crear si su

fuente es una función de agregación incorporada. Por ejemplo, si existe un tipo

diferenciado SHOESIZE que está definido con el tipo base INTEGER, es posible

definir una función, AVG(SHOESIZE), como función de agregación basada en la

función de agregación incorporada existente AVG(INTEGER).

2. También puede crear funciones que devuelvan una fila. Éstas se conocen como

funciones de fila y sólo se pueden utilizar como funciones de transformación

para los tipos estructurados. La salida de una función de salida es una única

fila.


v “Ventajas de utilizar rutinas” en Desarrollo de SQL y rutinas externas



página 280

v “Funciones de tabla de OLE DB definidas por el usuario” en Desarrollo de SQL y

rutinas externas


v “Funciones de tablas externas” en la página 281


v “Invocación de funciones o métodos escalares” en Desarrollo de SQL y rutinas

externas

v “Invocación de funciones de tabla definidas por el usuario” en Desarrollo de SQL

y rutinas externas


v “Sentencia CREATE FUNCTION” en Consulta de SQL, Volumen 2

Modelo de proceso de los métodos y las funciones escalares

externas

El modelo de proceso para los métodos y las UDF escalares que se definen con la

especificación FINAL CALL es el siguiente:

Llamada FIRST

Éste es un caso especial de la llamada NORMAL, identificado como FIRST

para permitir que la función realice cualquier proceso inicial. Se evalúan

los argumentos y se pasan a la función. Normalmente, la función

devolverá un valor en esta llamada, pero puede devolver un error, en cuyo

caso no se realiza ninguna llamada NORMAL ni FINAL. Si se devuelve un

error en una llamada FIRST, lo debe borrar el método o la UDF antes de

volver, puesto que no se realizará ninguna llamada FINAL.

Llamada NORMAL

Son las llamadas a la función que van de la segunda a la última, según

indiquen los datos y la lógica de la sentencia. Se espera que la función

devuelva un valor con cada llamada NORMAL después de que se evalúen

y pasen los argumentos. Si una llamada NORMAL devuelve un error, no

se realiza ninguna otra llamada NORMAL pero se realiza la llamada

FINAL.

Llamada FINAL

Ésta es una llamada especial, que se realiza en el proceso de fin de


sentencia (o en el cierre (CLOSE) de un cursor), siempre y cuando la

llamada FIRST sea satisfactoria. En una llamada FINAL no se pasa ningún

valor de argumento. Esta llamada se lleva a cabo para que la función

pueda borrar los recursos. La función no devuelve un valor en esta

llamada, pero puede devolver un error.

Si se trata de métodos o UDF escalares que no se han definido con FINAL CALL,

sólo se realizan llamadas NORMAL a la función, la cual habitualmente devuelve

un valor para cada llamada. Si una llamada NORMAL devuelve un error, o si la

sentencia encuentra otro error, no se realiza ninguna otra llamada a la función.

Nota: Este modelo describe el proceso de errores corriente para los métodos y las

UDF escalares. En el caso de una anomalía del sistema o un problema de

comunicación, no se puede efectuar una llamada indicada por el modelo de

proceso de errores. Por ejemplo, para una UDF FENCED, si el proceso

protegido db2udf termina de algún modo de forma prematura, DB2 no

puede efectuar las llamadas indicadas.




Funciones de tablas externas

Una función de tabla definida por el usuario entrega una tabla al SQL en el que se

le hace referencia. Una referencia a una UDF de tabla sólo es válida en una

cláusula FROM de una sentencia SELECT. Cuando utilice funciones de tabla, tenga

en cuenta lo siguiente:

v Aunque una función de tabla entrega una tabla, la interfaz física entre DB2 y la

UDF es de una fila cada vez. Hay cinco tipos de llamadas que se pueden

realizar a una función de tabla: OPEN, FETCH, CLOSE, FIRST y FINAL. La

existencia de las llamadas FIRST y FINAL depende de cómo se defina la UDF.

Para distinguir estas llamadas, se utiliza el mismo mecanismo de tipo-llamada

que se usa para las funciones escalares.

v No se tienen que devolver todas las columnas de resultado definidas en la

cláusula RETURNS de la sentencia CREATE FUNCTION para la función de

tabla. La palabra clave DBINFO de CREATE FUNCTION y el argumento dbinfo

correspondiente permiten una optimización consistente en que sólo haya que

devolver las columnas necesarias para una referencia a una función de tabla

determinada.

v Los valores de columna individuales devueltos se ajustan al formato de los

valores devueltos por las funciones escalares.

v La sentencia CREATE FUNCTION para una función de tabla tiene la

especificación CARDINALITY. Esta especificación permite que el creador

informe al optimizador de DB2 del tamaño aproximado del resultado, de forma

que el optimizador pueda tomar decisiones mejores cuando se haga referencia a

la función.

Independientemente de lo que se haya especificado como CARDINALITY de

una función de tabla, tenga cuidado respecto a la escritura de una función con

una cardinalidad infinita, es decir, una función que siempre devuelva una fila en

una llamada FETCH. Existen muchas situaciones en las que DB2 espera la

condición de fin de tabla como catalizador dentro del proceso de la consulta. La

utilización de GROUP BY u ORDER BY son ejemplos de este caso. DB2 no

puede formar los grupos de agregación hasta que se llega al fin de tabla, ni


puede realizar ninguna clasificación sin tener todos los datos. Por lo tanto, una

función de tabla que nunca devuelva la condición de fin de tabla (valor ’02000’

de estado de SQL) puede ocasionar un bucle infinito del proceso si se utiliza con

una cláusula GROUP BY u ORDER BY.






v “Paso de argumentos a rutinas C, C++, OLE o COBOL” en la página 342

Modelo de proceso para las funciones de tablas externas

El modelo de proceso para las UDF de tabla que se definen con la especificación

FINAL CALL es el siguiente:

Llamada FIRST

Esta llamada se realiza antes de la primera llamada OPEN y su objetivo

consiste en permitir que la función realice cualquier proceso inicial. Antes

de esta llamada, el área reutilizable se borra. Se evalúan los argumentos y

se pasan a la función. La función no devuelve una fila. Si la función

devuelve un error, no se realiza ninguna otra llamada a la misma.

Llamada OPEN

Esta llamada se realiza para permitir que la función realice un proceso

especial de apertura (OPEN) específico de la exploración. El área

reutilizable (si existe) no se borra antes de la llamada. Se evalúan los

argumentos y se pasan. La función no devuelve una fila en una llamada

OPEN. Si la función devuelve un error de la llamada OPEN, no se

realizará ninguna llamada FETCH ni CLOSE, pero sí se realizará la

llamada FINAL al final de la sentencia.

Llamada FETCH

Se siguen produciendo llamadas FETCH hasta que la función devuelve un

valor de SQLSTATE que significa fin-de-tabla. Es en estas llamadas donde

la UDF desarrolla y devuelve una fila de datos. Se pueden pasar valores de

argumentos a la función, pero éstos apuntan a los mismos valores que se

han pasado al ejecutar OPEN. Por lo tanto, es posible que los valores de

argumentos no sean actuales y no se debe confiar en ellos. Si tiene

necesidad de mantener valores actuales entre las invocaciones de una

función de tabla, utilice un área reutilizable. La función puede devolver un

error de una llamada FETCH, y la llamada CLOSE se seguirá produciendo.

Llamada CLOSE

Se realiza esta llamada cuando finaliza la exploración o sentencia, siempre

que la llamada OPEN haya resultado satisfactoria. Los posibles valores de

argumentos no serán actuales. La función puede devolver un error.

Llamada FINAL

Se realiza la llamada FINAL al final de la sentencia, siempre que la

llamada FIRST haya resultado satisfactoria. Esta llamada se lleva a cabo

para que la función pueda borrar los recursos. La función no devuelve un

valor en esta llamada, pero puede devolver un error.


Para las UDF de tabla no definidas con FINAL CALL, sólo se realizan las llamadas

OPEN, FETCH y CLOSE a la función. Antes de cada llamada OPEN, se borra el

área reutilizable (si existe).

La diferencia entre las UDF de tabla definidas con FINAL CALL y las definidas

con NO FINAL CALL se puede observar examinando un escenario que implique

una unión o una subconsulta, en que el acceso de la función de tabla es el acceso

″interior″. Por ejemplo, en una sentencia como la siguiente:

SELECT x,y,z,... FROM table_1 as A,

TABLE(table_func_1(A.col1,...)) as B

WHERE...

En este caso, el optimizador abrirá una exploración de table_func_1 para cada fila

de table_1. Esto es debido a que el valor de la col1 de table_1, que se pasa a

table_func_1, se utiliza para definir la exploración de la función de tabla.

Para las UDF de tabla con NO FINAL CALL, la secuencia de llamadas OPEN,

FETCH, FETCH, ..., CLOSE se repite para cada fila de table_1. Observe que cada

llamada OPEN obtendrá un área reutilizable limpia. Puesto que la función de tabla

no sabe, al final de cada exploración, si se producirán más exploraciones, la tiene

que limpiar completamente durante el proceso de cierre (CLOSE). Esto puede

resultar ineficaz si existe un proceso significativo de apertura de una sola vez que

se debe repetir.

Las UDF de tabla con FINAL CALL proporcionan una llamada FIRST de una sola

vez y una llamada FINAL de una sola vez. Estas llamadas se utilizan para

amortizar los costes de inicialización y terminación a lo largo de todas las

exploraciones de la función de tabla. Al igual que anteriormente, las llamadas

OPEN, FETCH, FETCH, ..., CLOSE se realizan para cada fila de la tabla exterior

pero, dado que la función de tabla sabe que obtendrá una llamada FINAL, no es

necesario que efectúe una limpieza completa en la llamada CLOSE (ni que la

reasigne en la OPEN posterior). Observe también que el área reutilizable no se

borra entre las exploraciones, en gran parte porque los recursos de la función de

tabla se repartirán a lo largo de las exploraciones.

A expensas de gestionar dos tipos de llamadas adicionales, la UDF de tabla puede

alcanzar una eficacia mayor en estos escenarios de unión y subconsulta. La

decisión de si se debe definir la función de tabla como FINAL CALL depende del

modo en que se pretenda utilizar.



v “Modelo de ejecución de funciones de tabla para Java” en la página 284

v “Funciones de tabla definidas por el usuario” en Desarrollo de SQL y rutinas

externas



v “Sentencia CREATE FUNCTION (Tabla externa OLE DB)” en Consulta de SQL,

Volumen 2

v “Sentencia CREATE FUNCTION (Escalar de SQL, tabla o fila)” en Consulta de

SQL, Volumen 2


Modelo de ejecución de funciones de tabla para Java

Para las funciones de tabla escritas en Java que utilizan PARAMETER STYLE

DB2GENERAL, es importante comprender lo que sucede en cada punto del

proceso de DB2 de una sentencia determinada. La tabla siguiente detalla esta

información para una función de tabla habitual. Se abarcan los casos de NO

FINAL CALL y de FINAL CALL, suponiendo en ambos casos SCRATCHPAD.

Punto en el tiempo de exploración NO FINAL CALL

LANGUAGE JAVA

SCRATCHPAD

FINAL CALL

LANGUAGE JAVA

SCRATCHPAD

Antes de la primera OPEN para la

función de tabla

No hay llamadas. v Se llama al constructor de clases

(por medio de la nueva área

reutilizable). Se llama al método de

UDF con la primera (FIRST)

llamada.

v El constructor inicializa las

variables de clase y área

reutilizable. El método conecta con

el servidor de Web.

En cada OPEN de la función de tabla v Se llama al constructor de clases

(por medio de la nueva área

reutilizable). Se llama al método de

UDF con la llamada OPEN.

v El constructor inicializa las

variables de clase y área

reutilizable. El método conecta con

el servidor de Web y abre la

exploración de los datos de la Web.

v Se abre el método de UDF con la

llamada OPEN.

v El método abre la exploración de

los datos de la Web que desee.

(Puede ser capaz de evitar que se

tenga que volver a abrir después

de una reposición de CLOSE,

según lo que se guarde en el área

reutilizable.)

En cada FETCH para una nueva fila

de datos de la función de tabla

v Se llama al método de UDF con la

llamada FETCH.

v El método capta y devuelve la

siguiente fila de datos, o bien EOT.


llamada FETCH.

v El método capta y devuelve la

nueva fila de datos, o bien EOT.

En cada CLOSE de la función de

tabla


llamada CLOSE. Método close(),

si existe para la clase.

v El método cierra su exploración de

la Web y se desconecta del

servidor de Web. No es necesario

que close() haga nada.


llamada CLOSE.

v El método puede reposicionarse al

principio de la exploración o

cerrarla. Puede guardar cualquier

estado en el área reutilizable, el

cual persistirá.

Después de la última CLOSE de la

función de tabla

No hay llamadas. v Se llama al método de UDF con la

llamada FINAL. Se llama al

método close(), si existe para la

clase.

v El método se desconecta del

servidor de Web. No es necesario

que el método close() haga nada.

Notas:

1. El término ″método de UDF″ hace referencia al método de clase de Java que

implementa la UDF. Se trata del método identificado en la cláusula EXTERNAL

NAME de la sentencia CREATE FUNCTION.

2. Para las funciones de tabla que tengan especificado NO SCRATCHPAD, las

llamadas al método de UDF son las indicadas en esta tabla, pero, puesto que el


usuario no solicita ninguna continuidad por medio de un área reutilizable, DB2

hará que se cree una instancia de un nuevo objeto antes de cada llamada,

llamando al constructor de clases. No está claro que las funciones de tabla con

NO SCRATCHPAD (y, por lo tanto, sin continuidad) puedan realizar acciones

útiles, pero se soportan.







v “Diseño de rutinas Java” en Desarrollo de SQL y rutinas externas



Áreas reutilizables para funciones externas y métodos

Un área reutilizable permite que una función definida por el usuario o un método

guarden su estado entre una invocación y la siguiente. Por ejemplo, a continuación

se identifican dos situaciones en las que guardar el estado entre las invocaciones es

beneficioso:

1. Las funciones o los métodos que, para ser correctos, dependen de que se

guarde el estado.

Un ejemplo de función o método de este tipo es una simple función de

contador que devuelve un '1' la primera vez que recibe llamada, e incrementa

el resultado en uno en cada llamada sucesiva. En algunas circunstancias, este

tipo de función se podría utilizar para numerar las filas del resultado de una

sentencia SELECT:

SELECT counter(), a, b+c, ...

FROM tablex

WHERE ...

La función necesita un lugar en el que almacenar el valor actual del contador

entre las invocaciones, donde se garantice que el valor será el mismo para la

siguiente invocación. Luego, en cada invocación se puede incrementar el valor

y devolverlo como resultado de la función.

Este tipo de rutina es NOT DETERMINISTIC. Su salida no depende

únicamente de los valores de sus argumentos de SQL.

2. Las funciones o los métodos en que se puede mejorar el rendimiento mediante

la posibilidad de realizar algunas acciones de inicialización.

Un ejemplo de función o método de este tipo, que puede formar parte de una

aplicación de documento, es una función match (de coincidencia), que devuelve

'Y' si un documento determinado contiene una serie indicada, y 'N' en caso

contrario:

SELECT docid, doctitle, docauthor

FROM docs

WHERE match(’myocardial infarction’, docid) = ’Y’

Esta sentencia devuelve todos los documentos que contienen el valor de serie

de texto concreto representado por el primer argumento. Lo que match desearía

hacer es:

v Sólo la primera vez.


Recuperar una lista de todos los ID de documento que contengan la serie

’myocardial infarction’ desde la aplicación de documento, que se mantiene

fuera de DB2. Esta recuperación es un proceso costoso, por lo que la función

desearía hacerlo una sola vez, y guardar la lista en algún lugar para tenerla a

mano en las llamadas posteriores.

v En cada llamada.

Utilizar la lista de los ID de documento guardada durante la primera

llamada, para ver si el ID de documento que se pasa como segundo

argumento está incluido en la lista.Este tipo de rutina es DETERMINISTIC. Su respuesta sólo depende de los

valores de los argumentos de entrada. Lo que se muestra aquí es una función

cuyo rendimiento, y no su corrección, depende de la posibilidad de guardar

información entre una llamada y la siguiente.

Ambas necesidades se satisfacen con la posibilidad de especificar un área

reutilizable (SCRATCHPAD) en la sentencia CREATE:

CREATE FUNCTION counter()

RETURNS int ... SCRATCHPAD;

CREATE FUNCTION match(varchar(200), char(15))

RETURNS char(1) ... SCRATCHPAD 10000;

La palabra clave SCRATCHPAD indica a DB2 que asigne y mantenga un área

reutilizable para una rutina. El tamaño por omisión de un área reutilizable es de

100 bytes, pero el usuario puede determinar el tamaño (en bytes) correspondiente a

un área reutilizable. El ejemplo de match presenta 10000 bytes de longitud. DB2

inicializa el área reutilizable con ceros binarios antes de la primera invocación. Si el

área reutilizable se define para una función de tabla, y si la función de tabla

también se define con NO FINAL CALL (valor por omisión), DB2 renueva el área

reutilizable antes de cada llamada a OPEN. Si se especifica la opción de función de

tabla FINAL CALL, DB2 no examinará ni cambiará el contenido del área

reutilizable después de su inicialización. Para las funciones escalares definidas con

áreas reutilizables, DB2 tampoco examina ni cambia el contenido del área después

de su inicialización. En cada invocación se pasa a la rutina un puntero al área

reutilizable, y DB2 conserva la información del estado de la rutina en el área

reutilizable.

Así, para el ejemplo de counter, el último valor devuelto se puede conservar en el

área reutilizable. Y, en el ejemplo de match, se puede conservar en el área

reutilizable la lista de documentos, en caso de que el área reutilizable sea

suficientemente grande; de lo contrario, se puede asignar memoria para la lista y

conservar la dirección de la memoria adquirida en el área reutilizable. Las áreas

reutilizables pueden tener una longitud variable: la longitud se define en la

sentencia CREATE para la rutina.

El área reutilizable únicamente se aplica a la referencia individual a la rutina en la

sentencia. Si en una sentencia existen varias referencias a una rutina, cada

referencia tiene su propia área reutilizable, por lo que estas áreas no se pueden

emplear para realizar comunicaciones entre referencias. El área reutilizable sólo se

aplica a un único agente de DB2 (un agente es una entidad de DB2 que realiza el

proceso de todos los aspectos de una sentencia). No existe un ″área reutilizable

global″ para coordinar el compartimiento de la información de las áreas

reutilizables entre los agentes. Esto es importante, en concreto, para aquellas

situaciones en que DB2 establece varios agentes para procesar una sentencia (ya

sea en una base de datos de una sola partición o de varias). En estos casos, aunque

una sentencia puede contener una sola referencia a una rutina, pueden existir


varios agentes que realicen el trabajo y cada uno de ellos tendrá su propia área

reutilizable. En una base de datos de varias particiones, donde una sentencia que

hace referencia a una UDF ha de procesar datos en varias particiones e invocar la

UDF en cada partición, el área reutilizable sólo se aplica a una partición. Como

consecuencia, existe un área reutilizable en cada partición en que se ejecuta la UDF.

Si la ejecución correcta de una función depende de que haya una sola área

reutilizable por cada referencia a la función, registre la función como DISALLOW

PARALLEL. Esto causará que la función se ejecute en una única partición y, de esta

manera, se garantizará que exista una única área reutilizable por cada referencia a

la función.

Puesto que es reconocido que una UDF o un método pueden requerir recursos del

sistema, la UDF o el método se pueden definir con la palabra clave FINAL CALL.

Esta palabra clave indica a DB2 que llame a la UDF o al método durante el

proceso de fin de sentencia, para que la UDF o el método puedan liberar sus

recursos del sistema. Es vital que una rutina libere cualquier recurso que adquiera;

incluso una pequeña fuga se puede convertir en una gran fuga en un entorno en

que la sentencia se invoque repetidamente, y una gran fuga puede provocar una

detención de DB2 por anomalía grave.

Puesto que el área reutilizable tiene un tamaño fijo, es posible que la UDF o el

método incluyan una asignación de memoria y por ello puedan utilizar la llamada

final para liberar la memoria. Por ejemplo, la función match anterior no puede

predecir cuántos documentos coincidirán con la serie de texto indicada. Por lo

tanto, la siguiente resultará una definición mejor para match:

CREATE FUNCTION match(varchar(200), char(15))

RETURNS char(1) ... SCRATCHPAD 10000 FINAL CALL;

Para las UDF o los métodos que emplean un área reutilizable y están referidos en

una subconsulta, DB2 puede efectuar una llamada final, si la UDF o el método se

especifican así, y renovar el área reutilizable entre invocaciones de la subconsulta.

El usuario se puede proteger frente a esta posibilidad, si las UDF o los métodos se

utilizan alguna vez en subconsultas, definiendo la UDF o el método con FINAL

CALL y utilizando el argumento de tipo de llamada o bien comprobando siempre

el estado de cero binario del área reutilizable.

Si especifica FINAL CALL, observe que la UDF o el método recibirán una llamada

del tipo FIRST. Se puede utilizar esta posibilidad para adquirir e inicializar algún

recurso persistente.

A continuación se muestra un ejemplo sencillo de Java de una UDF que utiliza un

área reutilizable para calcular la suma de los cuadrados de las entradas de una

columna. Este ejemplo toma una columna y devuelve una columna que contiene la

suma acumulada de cuadrados desde el principio de la columna hasta la entrada

de la fila actual:

CREATE FUNCTION SumOfSquares(INTEGER)

RETURNS INTEGER

EXTERNAL NAME ’UDFsrv!SumOfSquares’

DETERMINISTIC

NO EXTERNAL ACTION

FENCED

NOT NULL CALL

LANGUAGE JAVA

PARAMETER STYLE DB2GENERAL

NO SQL

SCRATCHPAD 10

FINAL CALL


DISALLOW PARALLEL

NO DBINFO@

// Suma de cuadrados utilizando la UDF Scratchpad

public void SumOfSquares(int inColumn,

int outSum)

throws Exception

{

int sum = 0;

byte[] scratchpad = getScratchpad();

// variables a leer de área SCRATCHPAD

ByteArrayInputStream byteArrayIn = new ByteArrayInputStream(scratchpad);

DataInputStream dataIn = new DataInputStream(byteArrayIn);

// variables a grabar en área SCRATCHPAD

byte[] byteArrayCounter;

int i;

ByteArrayOutputStream byteArrayOut = new ByteArrayOutputStream(10);

DataOutputStream dataOut = new DataOutputStream(byteArrayOut);

switch(getCallType())

{

case SQLUDF_FIRST_CALL:

// inicializar datos

sum = (inColumn * inColumn);

// guardar datos en área SCRATCHPAD

dataOut.writeInt(sum);

byteArrayCounter = byteArrayOut.toByteArray();

for(i = 0; i < byteArrayCounter.length; i++)

{

scratchpad[i] = byteArrayCounter[i];

}

setScratchpad(scratchpad);

break;

case SQLUDF_NORMAL_CALL:

// leer datos de área SCRATCHPAD

sum = dataIn.readInt();

// trabajar con datos

sum = sum + (inColumn * inColumn);

// guardar datos en área SCRATCHPAD

dataOut.writeInt(sum);

byteArrayCounter = byteArrayOut.toByteArray();

for(i = 0; i < byteArrayCounter.length; i++)

{

scratchpad[i] = byteArrayCounter[i];

}

setScratchpad(scratchpad);

break;

}

// establecer valor de salida

set(2, sum);

} // UDF SumOfSquares

Tenga en cuenta que se trata de una función incorporada de DB2 que realiza la

misma función que la UDF SumOfSquares. Se ha elegido este ejemplo para

demostrar el uso de un área reutilizable.


v “Área reutilizable como parámetro de función C o C++” en la página 329

v “Áreas reutilizables en sistemas operativos de 32 bits y 64 bits” en la página 289




página 280



v “Sentencia CREATE METHOD” en Consulta de SQL, Volumen 2

v “Sentencia CREATE TYPE (Estructurado)” en Consulta de SQL, Volumen 2


v “udfsrv.c -- Library of user-defined functions (UDFs) called by the client”

v “UDFCreate.db2 -- How to catalog the Java UDFs contained in UDFsrv.java ”

v “UDFsrv.java -- Provide UDFs to be called by UDFcli.java (JDBC)”

Áreas reutilizables en sistemas operativos de 32 bits y 64 bits

Para hacer que el código de la UDF o del método se pueda transportar entre

sistemas operativos de 32 bits y 64 bits, debe ir con precaución en la manera de

crear y utilizar las áreas reutilizables que contengan valores de 64 bits. Es

recomendable no declarar una variable de longitud explícita para una estructura de

área reutilizable que contenga uno o más valores de 64 bits, tales como los

punteros de 64 bits o las variables BIGINT sqlint64.

A continuación se muestra una declaración de estructura de ejemplo

correspondiente a un área reutilizable:

struct sql_scratchpad

{

sqlint32 length;

char data[100];

};

Cuando se define su propia estructura para el área reutilizable, una rutina tiene

dos opciones:

1. Redefinir el área reutilizable sql_scratchpad entera, en cuyo caso es necesario

incluir un campo de longitud explícito. Por ejemplo:

struct sql_spad

{

sqlint32 length;

sqlint32 int_var;

sqlint64 bigint_var;

};

void SQL_API_FN routine( ..., struct sql_spad* scratchpad, ... )

{

/* Utilizar área reutilizable */

}

2. Redefinir solamente la porción de datos del área reutilizable sql_scratchpad, en

cuyo caso no se necesita ningún campo de longitud.

struct spaddata

{

sqlint32 int_var;

sqlint64 bigint_var;

};

void SQL_API_FN routine( ..., struct sql_scratchpad* spad, ... )

{

struct spaddata* scratchpad = (struct spaddata*)spad→data;

/* Utilizar área reutilizable */

}


Puesto que la aplicación no puede cambiar el valor del campo de longitud del área

reutilizable, el hecho de codificar la rutina tal como se muestra en el primer

ejemplo no brinda ningún beneficio significativo. El segundo ejemplo también se

puede transportar entre sistemas de distintos tamaños de palabra, por lo que

representa la manera preferible de escribir la rutina.





v “Funciones de tabla definidas por el usuario” en Desarrollo de SQL y rutinas

externas


v “Invocación de rutinas de 32 bits en un servidor de bases de datos de 64 bits” en


API y lenguajes de programación soportados

Interfaces API y lenguajes de programación soportados para el

desarrollo de rutinas externas

Puede desarrollar rutinas externas de DB2 (procedimientos y funciones) utilizando

las siguientes API y los lenguajes de programación asociados:

v ADO.NET

– Lenguajes de programación .NET Common Language Runtimev CLI

v SQL incorporado

– C

– C++

– COBOL (solo para procedimientos)v JDBC

– Javav OLE

– Visual Basic

– Visual C++

– Cualquier otro lenguaje de programación que soporte esta API.v OLE DB (solo para funciones de tabla)

– Cualquier lenguaje de programación que soporte esta API.v SQLJ

– Java









externas

v “Elección de una interfaz de programación de aplicaciones” en Iniciación al

desarrollo de aplicaciones de bases de datos

v “Interfaces soportadas de programación de aplicaciones de bases de datos” en

Iniciación al desarrollo de aplicaciones de bases de datos



390

v “Lenguajes de programación y compiladores soportados para el desarrollo de

aplicaciones de bases de datos” en Iniciación al desarrollo de aplicaciones de bases de

datos

Comparación de las API y lenguajes de programación

soportados para el desarrollo de rutinas externas

Antes de empezar a implementar rutinas externas, es importante tener en cuenta

las características y las limitaciones de las distintas interfaces de programación de

aplicaciones (API) y lenguajes de programación soportados para las rutinas

externas. Con ello se asegurará de que elige la implementación adecuada desde el

principio y de que están disponibles las características de rutinas que necesite.

Tabla 25. Comparación de las API y lenguajes de programación de rutinas externas

API y lenguaje

de programación

Soporte de

características Rendimiento Seguridad Escalabilidad Limitaciones

SQL (incluye SQL

PL)

v SQL es un

lenguaje de alto

nivel fácil de

aprender y de

utilizar y que

agiliza la

implementación.

v Los elementos

SQL Procedural

Language (SQL

PL) permiten

utilizar la

lógica de flujo

de control en

operaciones y

consultas SQL.

v Soporte a tipos

de datos

firmes.

v Muy bueno.

v El rendimiento

de las rutinas

SQL es mejor

que el de las

rutinas Java.

v El rendimiento

de las rutinas

SQL es tan

bueno como el

de las rutinas

externas de C y

C++ creadas

con la cláusula

NOT FENCED.

v Muy seguro.

v Los

procedimientos

SQL se ejecutan

en la misma

memoria que el

gestor de bases

de datos.

v Gran

escalabilidad.

v No pueden

acceder al

sistema de

archivos del

servidor de

bases de datos.

v No pueden

invocar

aplicaciones

que residan

fuera de la base

de datos.


Tabla 25. Comparación de las API y lenguajes de programación de rutinas externas (continuación)

API y lenguaje

de programación

Soporte de


SQL incorporado

(incluye C y C++)

v Lenguaje de

programación

de bajo nivel,

pero potente.

v Muy bueno.

v El rendimiento

de las rutinas

de C y C++ es

mejor que el de

las rutinas Java.

v El rendimiento

de las rutinas

de C y C++

creadas con la

cláusula NOT

FENCED es tan

bueno como el

de las rutinas

SQL.

v Las rutinas de

C y C++ son

susceptibles a

los errores de

programación.

v Los

programadores

deben tener un

buen dominio

del lenguaje C

para evitar

cometer errores

de memoria y

de

manipulación

de punteros

muy comunes

que hacen que

la

implementación

de las rutinas

sea más pesada

y requiera más

tiempo.

v Las rutinas de

C y C++ deben

crearse con la

cláusula

FENCED y la

cláusula NOT

THREADSAFE

para evitar la

interrupción

del gestor de

bases de datos

en caso de que

se produzca

una excepción

en la rutina en

tiempo de

ejecución. Éstas

son las

cláusulas por

omisión. La

utilización de

estas cláusulas

puede tener un

cierto efecto

negativo sobre

el rendimiento

pero garantiza

una ejecución

segura.

Consulte:

Seguridad de

las rutinas .

v La

escalabilidad es

limitada

cuando se

crean rutinas

de C y C++

con las

cláusulas

FENCED y

NOT

THREADSAFE.

Estas rutinas se

ejecutan en un

proceso db2fmp

independiente

del proceso del

gestor de bases

de datos. Se

necesita un

proceso db2fmp

para cada

rutina que se

ejecute de

forma

simultánea.

v Existen

múltiples

estilos para

pasar los

parámetros

soportados y

esto puede

resultar

confuso. Los

usuarios deben

utilizar siempre

que sea posible

el estilo de los

parámetros

SQL.



API y lenguaje

de programación

Soporte de


SQL incorporado

(COBOL)

v Lenguaje de

programación

de alto nivel

adecuado para

el desarrollo de

aplicaciones

empresariales

que suelen ir

orientadas a

archivos.

v Utilizado de

forma

generalizada en

el pasado para

las aplicaciones

empresariales

de producción,

aunque su

popularidad

está decayendo.

v COBOL no

contiene

soporte a los

punteros y es

un lenguaje de

programación

iterativo y

lineal.

v El rendimiento

de las rutinas

de COBOL no

es tan bueno

como el de las

rutinas creadas

con el resto de

opciones de

implementación

de rutinas

externas.

v No hay

información

disponible en

estos

momentos.

v No hay

información

disponible en

estos

momentos.

v Es posible crear

e invocar

procedimientos

de COBOL de

32 bits en

instancias de

DB2 de 64 bits;

sin embargo, el

rendimiento de

estas rutinas no

será tan bueno

como el de los

procedimientos

de COBOL de

64 bits de una

instancia de

DB2 de 64 bits.

JDBC (Java) y

SQLJ (Java)

v Lenguaje de

programación

de alto nivel

orientado a

objetos

adecuado para

el desarrollo de

aplicaciones

autónomas,

applets y

servlets.

v Los objetos y

los tipos de

datos de Java

facilitan el

establecimiento

de conexiones

con la base de

datos, la

ejecución de las

sentencias SQL

y la

manipulación

de los datos.

v El rendimiento

de las rutinas

de Java es tan

bueno como el

de las rutinas

de C y C++ o

el de las

rutinas SQL.

v Las rutinas de

Java son más

seguras que las

rutinas de C y

C++ porque la

Máquina

virtual Java

(JVM) es quien

gestiona el

control de las

operaciones

peligrosas. Esto

aumenta la

fiabilidad y

hace que

resulte difícil

que el código

de una rutina

de Java

perjudique a

otra rutina que

se ejecute en el

mismo proceso.

v Buena

escalabilidad

v Las rutinas

Java creadas

con la cláusula

FENCED

THREADSAFE

(el valor por

omisión) tienen

una buena

escalabilidad.

Todas las

rutinas Java

protegidas

comparten

algunas JVM.

Es posible que

se utilice más

de una JVM en

el sistema si la

pila de Java de

un proceso

db2fmp

concreto está

próxima a su

agotamiento.

v Para evitar

operaciones

potencialmente

peligrosas, no

se permiten

llamadas JNI

(Java Native

Interface) desde

las rutinas Java.



API y lenguaje

de programación

Soporte de


Lenguajes

soportados de

ejecución en el

lenguaje común

(CLR) .NET

(incluidos C#,

Visual Basic y

otros)

v Parte del

modelo de

código

gestionado

.NET de

Microsoft.

v El código

fuente se

compila en el

bytecode de

lenguaje

intermedio (IL)

que se puede

interpretar

mediante la

unidad

ejecutable de

lenguaje común

(CLR)

Microsoft .NET

Framework.

v Los

ensamblajes

CLR se pueden

crear a partir

de

subensamblajes

que se hayan

compilado con

diferente

código fuente

de lenguaje de

programación

.NET, lo que

permite a los

usuarios

reutilizar e

integrar

módulos de

código escritos

en varios

lenguajes.

v Las rutinas

CLR solo se

pueden crear

con la cláusula

FENCED NOT

THREADSAFE

para minimizar

la posibilidad

de una

interrupción

del gestor de

bases de datos

durante el

tiempo de

ejecución. Esto

puede tener un

cierto efecto

negativo sobre

el rendimiento.

v Las rutinas

CLR solo se

pueden crear

con la cláusula

FENCED NOT

THREADSAFE.

Por lo tanto,

son seguras

porque se

ejecutarán

fuera del gestor

de bases de

datos en un

proceso

db2fmp aparte.

v No hay

información

disponible.

v Consulte el

tema

″Restricciones

de las rutinas

CLR .NET″.



API y lenguaje

de programación

Soporte de


v OLE v Las rutinas de

OLE se pueden

implantar en

Visual C++, en

Visual Basic y

en otros

lenguajes

soportados por

OLE.

v La velocidad

de las rutinas

automatizadas

OLE dependerá

del lenguaje

utilizado para

implementarlas.

En general, son

más lentas que

las rutinas

C/C++ que no

son OLE.

v Las rutinas

OLE solo se

pueden ejecutar

en modalidad

FENCED NOT

THREADSAFE

y, por lo tanto,

las rutinas

automatizadas

OLE tienen una

buena

escalabilidad.

v No hay

información

disponible.

v No hay

información

disponible.

v No hay

información

disponible.



API y lenguaje

de programación

Soporte de


v OLE DB v OLE DB se

puede utilizar

para crear

funciones de

tabla definidas

por el usuario.

v Las funciones

OLE DB

establecen

conexión con

fuentes de

datos externas

OLE DB.

v El rendimiento

de las

funciones OLE

DB depende

del proveedor

de OLE DB; sin

embargo, en

general las

funciones OLE

DB ofrecen un

mejor

rendimiento

que las

funciones Java

equivalente en

términos

lógicos pero

menor que las

funciones C,

C++ o SQL

equivalentes en

términos

lógicos. No

obstante,

algunos

predicados de

la consulta en

que se invoca

la función se

pueden evaluar

en el proveedor

de OLE DB,

por lo que

quedará

reducido el

número de filas

que DB2 tenga

que procesar, lo

que suele dar

lugar a un

mejor

rendimiento.

v No hay

información

disponible.

v No hay

información

disponible.

v OLE DB sólo se

puede utilizar

para crear

funciones de

tabla definidas

por el usuario.


v “Interfaces soportadas de programación de aplicaciones de bases de datos” en







externas







datos


390

Creación de rutinas externas

Las rutinas externas se crean de manera parecida a cómo se crean rutinas con otras

implementaciones. Sin embargo, se necesitan algunos pasos adicionales porque,

para implementar la rutina, hay que escribir código fuente, compilarlo y

desplegarlo.

Una rutina externa consta de dos partes:

v La sentencia CREATE que define la rutina.

v La biblioteca o clase externa que implementa el cuerpo de la rutina.

Cuando la sentencia CREATE que define una rutina se ejecuta satisfactoriamente,

la rutina se crea en la base de datos. La sentencia debe definir como mínimo el

nombre de la rutina, la signatura de parámetros que se usará en la implementación

de la rutina, y la ubicación de la biblioteca o clase externa construida a partir del

código fuente de la implementación de la rutina.

El código de implementación de las rutinas externas debe estar escrito en uno de

los lenguajes de programación soportados y luego hay que incorporarlo en un

archivo de clase o biblioteca que debe estar instalado en el sistema de archivos del

servidor de base de datos.

Una rutina externa no se puede invocar satisfactoriamente hasta que se ha creado

en la base de datos y hasta que la biblioteca o clase asociada a la rutina se ha

colocado en la ubicación especificada por la cláusula EXTERNAL.

El desarrollo de rutinas externas suele consistir en las siguientes tareas:

v Determinar qué tipo funcional de rutina hay que implementar.

v Elegir uno de los lenguajes de programación soportados para las rutinas

externas de cara a su implementación.

v Diseñar la rutina.

v Conectar con una base de datos y crear la rutina en la base de datos.

– Para ello, se ejecuta una de las sentencias CREATE PROCEDURE, CREATE

FUNCTION o CREATE METHOD o se utiliza una herramienta gráfica que

automatice este paso.

– Esta tarea, también conocida como definición o registro de una rutina, se

puede realizar en cualquier momento antes de invocar la rutina, excepto en

las circunstancias siguientes:

- Para las rutinas Java que hacen referencia a un archivo o archivos JAR

externos, el código y los archivos JAR externos se deben codificar y

compilar antes de que la rutina se cree en la base de datos utilizando la

sentencia CREATE específica del tipo de rutina.

- Las rutinas que ejecutan sentencias SQL y se refieren directamente a sí

mismas se deben crear en la base de datos emitiendo la sentencia CREATE

antes de que se precompile y enlace el código externo asociado con la


rutina. Esto también es aplicable a las situaciones en que exista un ciclo de

referencias; por ejemplo: la Rutina A hace referencia a la Rutina B, la cual

hace referencia a la Rutina A.v Escribir el código de la lógica de la rutina para que se corresponda con la

definición de la rutina.

v Construir la rutina y generar un archivo de clase o biblioteca.

– En el caso de las rutinas de SQL incorporado, incluye: precompilar, compilar

y enlazar el código, así como enlazar el paquete de la rutina con la base de

datos destino.

– En el caso de las rutinas de SQL no incorporado, incluye: compilar y enlazar

el código.v Desplegar el archivo de clase o biblioteca en el servidor de base de datos, en la

ubicación especificada en la definición de la rutina.

v Otorgar el privilegio EXECUTE sobre la rutina al invocador o invocadores de la

rutina (si no son los que han definido la rutina).

v Invocar, probar y depurar la rutina.

Todos los pasos necesarios para crear una rutina externa se pueden realizar

mediante el procesador de línea de mandatos de DB2 o mediante una ventana de

mandatos de DB2. Hay herramientas que pueden ayudar a automatizar algunos de

estos pasos o todos ellos.







Estilos de parámetros de rutinas externas

Las implementaciones de rutinas externas se tienen que ajustar a un convenio

determinado para el intercambio de valores de parámetros de la rutina. Estos

convenios se conocen como estilos de parámetros. Se especifica un estilo de

parámetros de rutina externa cuando se crea la rutina, especificando la cláusula

PARAMETER STYLE. Los estilos de parámetros caracterizan la especificación y el

orden en el que se pasarán los valores de los parámetros a la implementación de la

rutina externa. también especifican qué pasará si se pasan valores adicionales a la

implementación de la rutina externa. Por ejemplo, algunos estilos de parámetros

especifican que para cada valor de parámetro de rutina se debe pasar un valor de

indicador de nulo adicional por separado a la implementación de la rutina para

proporcionar información sobre la capacidad de nulos de los parámetros, lo que de

lo contrario no se puede determinar fácilmente con un tipo de datos del lenguaje

de programación nativo.

La tabla siguiente proporciona una lista de los estilos de parámetros disponibles,

las implementaciones de rutina que dan soporte a cada estilo de parámetros, los

tipos de rutinas funcionales que dan soporte a cada estilo de parámetros y una

descripción del estilo de parámetros:


Tabla 26. Estilos de parámetros

Estilo de

parámetros

Lenguaje

soportado

Tipo de rutina

soportado Descripción

SQL

1

v C/C++

v OLE

v Lenguajes de

ejecución en el

lenguaje

común .NET

v COBOL

2

v UDF

v procedim.

almacenados

v métodos

Además de los parámetros que se pasan durante la invocación, se pasan a

la rutina los argumentos siguientes por este orden:

v Un indicador nulo para cada parámetro o resultado declarado en la

sentencia CREATE.

v El SQLSTATE que se debe devolver a DB2.

v El nombre calificado de la rutina.

v El nombre específico de la rutina.

v La serie de diagnóstico de SQL que se debe devolver a DB2.

Según las opciones especificadas en la sentencia CREATE y el tipo de

rutina, se pueden pasar a la rutina los argumentos siguientes por este

orden:

v Un almacenamiento intermedio para el área reutilizable.

v El tipo de llamada de la rutina.

v La estructura dbinfo (contiene información acerca de la base de datos).

DB2SQL

1

v C/C++

v OLE

v Lenguajes de

ejecución en el

lenguaje

común .NET

v COBOL

v procedim.

almacenados

Además de los parámetros que se pasan durante la invocación, se pasan al

procedimiento almacenado los argumentos siguientes por este orden:

v Un vector que contiene un indicador nulo para cada parámetro de la

sentencia CALL.

v El SQLSTATE que se debe devolver a DB2.

v El nombre calificado del procedimiento almacenado.

v El nombre específico del procedimiento almacenado.

v La serie de diagnóstico de SQL que se debe devolver a DB2.

Si se especifica la cláusula DBINFO en la sentencia CREATE PROCEDURE,

se pasa al procedimiento almacenado una estructura dbinfo (contiene

información acerca de la base de datos).

JAVA

v Java v UDF

v procedim.

almacenados

Las rutinas con PARAMETER STYLE JAVA utilizan un convenio de pase de

parámetros que cumple con la especificación del lenguaje Java y las rutinas

de SQLJ.

Para los procedimientos almacenados, los parámetros INOUT y OUT se

pasarán como matrices de entrada única para facilitar la devolución de

valores. Además de los parámetros IN, OUT e INOUT, las signaturas de

método Java de los procedimientos almacenados incluyen un parámetro del

tipo ResultSet[] para cada conjunto de resultados especificado en la cláusula

DYNAMIC RESULT SETS de la sentencia CREATE PROCEDURE.

Para las UDF y los métodos con PARAMETER STYLE JAVA, no se pasan

más argumentos que los especificados en la invocación de la rutina.

Las rutinas PARAMETER STYLE JAVA no proporcionan soporte a las

cláusulas DBINFO o PROGRAM TYPE. Para las UDF, PARAMETER STYLE

JAVA sólo puede especificarse si no se han especificado como parámetros

tipos de datos estructurados y no se ha especificado como tipo de retorno

ningún tipo de datos estructurado, CLOB, DBCLOB ni BLOB (SQLSTATE

429B8). Además las UDF de PARAMETER STYLE JAVA no proporcionan

soporte a las funciones de tabla, los tipos de llamada ni áreas reutilizables.

DB2GENERAL

v Java v UDF

v procedim.

almacenados

v métodos

Este tipo de rutina utilizará un convenio de pase de parámetros definido

para su uso con los métodos Java. A no ser que se desarrollen UDF de tabla

o UDF con áreas reutilizables o que se tenga que acceder a la estructura

dbinfo, es recomendable utilizar PARAMETER STYLE JAVA.

Para las rutinas con PARAMETER STYLE DB2GENERAL, no se pasa

ningún argumento adicional aparte de los especificados en la invocación de

la rutina.


Tabla 26. Estilos de parámetros (continuación)

Estilo de

parámetros

Lenguaje

soportado

Tipo de rutina

soportado Descripción

GENERAL

v C/C++

v Lenguajes de

ejecución en el

lenguaje

común .NET

v COBOL

v procedim.

almacenados

Un procedimiento almacenado con PARAMETER STYLE GENERAL recibe

parámetros de la sentencia CALL en la aplicación o rutina que realiza la

invocación. Si se especifica la cláusula DBINFO en la sentencia CREATE

PROCEDURE, se pasa al procedimiento almacenado una estructura dbinfo

(contiene información acerca de la base de datos).

GENERAL es el equivalente de los procedimientos almacenados SIMPLE en

DB2 Universal Database para z/OS y OS/390.

GENERAL

WITH NULLS

v C/C++

v Lenguajes de

ejecución en el

lenguaje

común .NET

v COBOL

v procedim.

almacenados

Un procedimiento almacenado con PARAMETER STYLE GENERAL WITH

NULLS recibe parámetros de la sentencia CALL en la aplicación o rutina

que realiza la invocación. También se incluye un vector que contiene un

indicador nulo para cada parámetro de la sentencia CALL. Si se especifica

la cláusula DBINFO en la sentencia CREATE PROCEDURE, se pasa al

procedimiento almacenado una estructura dbinfo (contiene información

acerca de la base de datos).

GENERAL WITH NULLS es el equivalente de los procedimientos

almacenados SIMPLE WITH NULLS en DB2 Universal Database para z/OS

y OS/390.

Nota:

1. Para las UDF y los métodos, PARAMETER STYLE SQL es equivalente a

PARAMETER STYLE DB2SQL.

2. COBOL sólo se puede utilizar para desarrollar procedimientos

almacenados.

3. Los métodos de ejecución en el lenguaje común .NET no están

soportados.





v “Parámetros de las rutinas de CLR .NET” en Desarrollo de SQL y rutinas externas

v “Parámetros de rutinas C y C++” en la página 319

v “Parámetros en rutinas Java” en Desarrollo de SQL y rutinas externas

v “Parámetros de los procedimientos de SQL” en Desarrollo de SQL y rutinas

externas


v “Tipos diferenciados como UDF o parámetros de método” en Desarrollo de SQL y

rutinas externas

v “Pase de parámetros de tipo estructurado a rutinas externas” en Desarrollo de





v “Sentencia CREATE PROCEDURE” en Consulta de SQL, Volumen 2




Gestión de bibliotecas o clases de rutinas

Gestión de bibliotecas y clases de rutinas externas

Para desarrollar e invocar rutinas externas satisfactoriamente, los archivos de

bibliotecas y de clases de rutinas externas deben desplegarse y gestionarse

debidamente.

La gestión de archivos de bibliotecas y de clases de rutinas externas puede ser

mínima si se tiene cuidado cuando se crean las rutinas externas por primera vez y

se despliegan archivos de bibliotecas y clases de rutinas externas.

Las principales consideraciones a tener en cuenta sobre la gestión de rutinas

externas son las siguientes:

v Despliegue de archivos de bibliotecas y de clases de rutinas externas

v Seguridad de archivos de bibliotecas y de clases de rutinas externas

v Resolución de bibliotecas y clases de rutinas externas

v Modificaciones de archivos de bibliotecas y de clases de rutinas externas

v Copia de seguridad y restauración de archivos de bibliotecas y de clases de

rutinas externas

Los administradores del sistema, los administradores de bases de datos y los

desarrolladores de aplicaciones de bases de datos deben responsabilizarse de

garantizar que los archivos de bibliotecas y de clases de las rutinas externas están

protegidos y correctamente conservados durante las tareas de desarrollo de rutinas

y de administración de bases de datos.


v “Copia de seguridad y restauración de archivos de bibliotecas y clases de rutinas

externas” en la página 305

v “Despliegue de bibliotecas y clases de rutinas externas” en la página 301


v “Resolución de bibliotecas y clases de rutinas externas” en la página 303


v “Seguridad de archivos de bibliotecas o clases de rutinas externas” en la página

303

v “Modificaciones de archivos de bibliotecas y clases de rutinas externas” en la

página 304


v “Sentencia ALTER FUNCTION” en Consulta de SQL, Volumen 2

v “Sentencia ALTER METHOD” en Consulta de SQL, Volumen 2

v “Sentencia ALTER PROCEDURE” en Consulta de SQL, Volumen 2




Despliegue de bibliotecas y clases de rutinas externas

El despliegue de bibliotecas y clases de rutinas externas consiste en copiar las

bibliotecas y clases de las rutinas externas en el servidor de bases de datos cuando

se han creado a partir del código fuente.


Los archivos de biblioteca, clase o ensamblaje de la rutina externa se tienen que

copiar en el directorio function de DB2 o en un subdirectorio de este directorio en el

servidor de bases de datos. Esta es la ubicación recomendada para el despliegue de

rutinas externas. Para obtener más información sobre el directorio de función,

consulte la descripción de la cláusula EXTERNAL correspondiente a cualquiera de

las siguientes sentencias SQL: CREATE PROCEDURE o CREATE FUNCTION.

Puede copiar la clase, biblioteca o ensamblaje de la rutina externa en otras

ubicaciones de directorios del servidor, en función de la API y el lenguaje de

programación utilizados para implementar la rutina, aunque no se recomienda

hacerlo en general. Si se hace, para invocar satisfactoriamente la rutina debe anotar

el nombre de la vía de acceso calificada al completo y asegurarse de que se utilice

este valor con la cláusula EXTERNAL NAME.

Los archivos de biblioteca y de clase se pueden copiar en el sistema de archivos

del servidor de bases de datos mediante las herramientas de transferencia de

archivos disponibles de manera más general. Las rutinas Java fr un sistema

informático en el que esté instalado un cliente DB2 se pueden copiar en un

servidor de bases de datos DB2 mediante procedimientos especiales definidos por

el sistema diseñados específicamente para ello. Encontrará más detalles en los

temas sobre rutinas Java.

Cuando ejecute la sentencia CREATE del lenguaje SQL adecuado correspondiente

al tipo de rutina, CREATE PROCEDURE o CREATE FUNCTION, asegúrese de

especificar las cláusulas adecuadas, prestando especial atención en la cláusula

EXTERNAL NAME.

v Especifique la cláusula LANGUAGE con el valor adecuado correspondiente a la API

o lenguaje de programación elegido. Ejemplos: CLR, C, JAVA.

v Especifique la cláusula PARAMETER STYLE con el nombre del estilo de parámetros

soportado que se ha implementado en el código de la rutina.

v Especifique la cláusula EXTERNAL con el nombre del archivo de biblioteca, clase o

ensamblaje que se ha de asociar a la rutina utilizando uno de los valores

siguientes:

– el nombre de vía de acceso calificado al completo del archivo de biblioteca,

clase o ensamblaje de la rutina.

– el nombre de vía de acceso relativa del archivo de biblioteca, clase o

ensamblaje de la rutina con relación al directorio de función.

Por omisión, DB2 buscará el archivo de biblioteca, clase o ensamblaje por el

nombre en el directorio de función, a menos que se especifique un nombre de vía

de acceso completamente calificado o relativo para el archivo en la cláusula

EXTERNAL.


v “Gestión y rendimiento de bibliotecas de rutinas externas” en la página 305


página 304

v “Resolución de bibliotecas y clases de rutinas externas” en la página 303


303





Seguridad de archivos de bibliotecas o clases de rutinas

externas

Las bibliotecas de las rutinas externas se almacenan en el sistema de archivos en el

servidor de bases de datos, y el gestor de bases de datos de DB2 no hace copia de

ellas ni las protege de ningún modo. Para que se pueda seguir invocando

satisfactoriamente las rutinas, es imprescindible que la biblioteca asociada a la

rutina continúe existiendo en la ubicación especificada en la cláusula EXTERNAL

de la sentencia CREATE utilizada para crear la rutina. No mueva ni suprima

bibliotecas de rutinas después de crear las rutinas; de lo contrario, las invocaciones

de las rutinas fallarían.

Para evitar que las bibliotecas de rutinas se supriman o sustituyan de forma

accidental o intencionada, debe restringir el acceso a los directorios del servidor de

bases de datos que contienen bibliotecas de rutinas y restringir el acceso a los

archivos de bibliotecas de rutinas. Esto se puede realizar utilizando mandatos del

sistema operativo para establecer permisos sobre directorios y archivos.







página 304

Resolución de bibliotecas y clases de rutinas externas

La resolución de bibliotecas de rutinas externas de DB2 se realiza a nivel de

instancia de DB2. Esto significa que, en instancias de DB2 que contienen varias

bases de datos de DB2, se pueden crear rutinas externas en una base de datos que

utilicen bibliotecas de rutinas externas que ya se utilicen para una rutina en otra

base de datos.

La resolución de rutinas externas a nivel de instancia da soporte a la reutilización

de código, permitiendo asociar varias definiciones de rutina a una sola biblioteca.

Cuando las bibliotecas de rutinas externas no se reutilizan de esta forma, sino que

existen copias de la biblioteca de la rutina externa en el sistema de archivos del

servidor de bases de datos, pueden producirse conflictos de nombres de

bibliotecas. Esto puede suceder concretamente cuando hay varias bases de datos en

una sola instancia y las rutinas de cada base de datos se asocian a sus propias

copias de bibliotecas y clases de cuerpos de rutinas. Se produce un conflicto

cuando el nombre de una biblioteca o de una clase utilizado por una rutina de una

base de datos es idéntico al nombre de la biblioteca o clase utilizado por una

rutina de otra base de datos (de la misma instancia).

Para minimizar la probabilidad de que esto suceda, se recomienda almacenar una

sola copia de una biblioteca de rutina en el directorio de función de nivel de

instancia (directorio sqllib/function) y que la cláusula EXTERNAL de todas las

definiciones de rutinas de cada una de las bases de datos haga referencia a la

biblioteca exclusiva.

Si se tienen que crear dos bibliotecas de rutinas funcionalmente diferentes con el

mismo nombre, es importante realizar pasos adicionales para minimizar la

probabilidad de que se produzcan conflictos de nombres de bibliotecas.


Para rutinas C, C++, COBOL y ADO.NET:

Los conflictos de nombres de bibliotecas se pueden minimizar o resolver:

1. Almacenando las bibliotecas con los cuerpos de las rutinas en distintos

directorios para cada base de datos.

2. Creando las rutinas con un valor de cláusula EXTERNAL NAME que

especifique la vía de acceso completa de una determinada biblioteca (en

lugar de una vía de acceso relativa).

Para rutinas Java:

Los conflictos de nombres de clase no se pueden resolver moviendo los

archivos de clase en cuestión a directorios diferentes, porque la variable de

entorno CLASSPATH tiene efecto en toda la instancia. La primera clase que

se encuentra en CLASSPATH es la que se utiliza. Por lo tanto, si tiene dos

rutinas Java diferentes que hacen referencia a una clase con el mismo

nombre, una de las rutinas utilizará una clase incorrecta. Existen dos

soluciones posibles: renombre las clases afectadas o cree una instancia

distinta para cada base de datos.







página 304


303

Modificaciones de archivos de bibliotecas y clases de rutinas

externas

Puede ser necesario modificar la lógica de una rutina externa existente después de

que una rutina externa se despliegue y se utilice en un entorno del sistema de

bases de datos de producción. Se pueden realizar modificaciones en las rutinas

existentes, pero hay que realizarlas cuidadosamente para definir un momento de

toma de control claro para las actualizaciones y para minimizar el riesgo de que se

produzcan interrupciones en cualquier invocación concurrente de la rutina.

Si una biblioteca de rutina externa necesita una actualización, no vuelva a compilar

y a enlazar la rutina con el mismo archivo de destino (por ejemplo,

sqllib/function/foo.a) que utiliza la rutina actual mientras se está ejecutando el

gestor de bases de datos. Si una invocación de rutina actual accede a una versión

en antememoria del proceso de la rutina y se sustituye la biblioteca subyacente, la

invocación de la rutina puede fallar. Si hay que modificar el cuerpo de una rutina

sin detener y volver a iniciar DB2, siga los pasos siguientes:

1. Cree la nueva biblioteca de rutina externa con otro nombre de archivo de

biblioteca o de clase.

2. Si se trata de una rutina de SQL incorporado, enlace el paquete de la rutina a la

base de datos con el mandato BIND.

3. Utilice la sentencia ALTER ROUTINE para cambiar la definición de la rutina

para que la cláusula EXTERNAL NAME haga referencia a la biblioteca o clase

de la rutina actualizada. Si el cuerpo de rutina que se debe actualizar lo utilizan

rutinas catalogadas en varias bases de datos, las acciones recomendadas en esta

sección se deberán llevar a cabo para cada base de datos afectada.


4. Para actualizar rutinas Java incorporadas en archivos JAR, tiene que emitir una

sentencia CALL SQLJ.REFRESH_CLASSES() a fin de forzar que DB2 cargue las

nuevas clases. Si no emite la sentencia CALL SQLJ.REFRESH_CLASSES()

después de actualizar las clases de rutinas Java, DB2 continúa utilizando las

versiones anteriores de las clases. DB2 renueva las clases cuando se produce

una operación COMMIT o ROLLBACK.

Una vez actualizada la definición de la rutina, las siguientes invocaciones de la

rutina cargarán y ejecutarán la nueva biblioteca o clase de rutina externa.







303

Copia de seguridad y restauración de archivos de bibliotecas y

clases de rutinas externas

No se hace copia de seguridad de las bibliotecas de rutinas externas con otros

objetos de base de datos cuando se realiza una copia de seguridad de la base de

datos. Tampoco se restauran cuando se restaura una base de datos.

Si el objetivo de una operación de copia de seguridad y restauración de una base

de datos es redesplegar una base de datos, los archivos de bibliotecas de rutinas

externas del sistema de archivos del servidor de bases de datos original se tienen

que copiar en el sistema de archivos del servidor de bases de datos de destino, de

forma que se conserven los nombres de vías de acceso relativas de las bibliotecas

de rutinas externas.





página 304


303

Gestión y rendimiento de bibliotecas de rutinas externas

La gestión de bibliotecas de rutinas externas puede afectar al rendimiento de las

rutinas, puesto que el gestor de bases de datos de DB2 coloca en antememoria de

forma dinámica las bibliotecas de rutinas externas a fin de mejorar el rendimiento

de acuerdo con el uso de las rutinas. para conseguir un rendimiento óptimo de las

rutinas externas, tenga en cuenta lo siguiente:

v Haga que el número de rutinas de cada biblioteca sea lo más reducido posible.

Es mejor tener muchas bibliotecas de rutinas externas pequeñas que unas pocas

de gran tamaño.

v Agrupe dentro del código fuente las funciones de las rutinas que se suelen

invocar juntas. Cuando el código se compila en una biblioteca de rutinas

externas, los puntos de entrada de las rutinas que se invocan con frecuencia

estarán juntos, lo que permite al gestor de bases de datos ofrecer un mejor


soporte de colocación en antememoria. El soporte mejorado de colocación en

antememoria se debe a la eficacia que se puede obtener al cargar una sola

biblioteca de rutinas externas una vez y luego invocar varias funciones de

rutinas externas dentro de dicha biblioteca.

Para las rutinas externas implementadas en el lenguaje de programación C o

C++, el coste de cargar una biblioteca se paga una vez para las bibliotecas que se

encuentran en uso de forma coherente por parte de las rutinas C. Después de la

primera invocación de la rutina, no es necesario que todas las invocaciones

posteriores, de la misma hebra del proceso, vuelvan a cargar la biblioteca de la

rutina.






página 304


v “Sustitución de una biblioteca compartida de AIX” en Desarrollo de SQL y rutinas

externas

Soporte de 32 bits y 64 bits para rutinas externas

El soporte para rutinas externas de 32 bits y 64 bits está determinado por la

especificación de una de las dos cláusulas siguientes en la sentencia CREATE para

las rutinas: cláusula FENCED o cláusula NOT FENCED.

El cuerpo de la rutina de una rutina externa se escribe en un lenguaje de

programación y se compila en una biblioteca o archivo de clase que luego se carga

y se ejecuta cuando se invoca la rutina. La especificación de la cláusula FENCED o

NOT FENCED determina si la rutina externa se ejecuta en un entorno con barrera

diferenciado del gestor de bases de datos o en el mismo espacio de direcciones que

el gestor de bases de datos, lo que puede ofrecer un mejor rendimiento mediante el

uso de memoria compartida en vez de TCPIP para las comunicaciones. Por

omisión, las rutinas siempre se crean con barrera independientemente de las otras

cláusulas seleccionadas.

La tabla siguiente ilustra el soporte de DB2 para ejecutar rutinas de 32 bits y 64

bits con y sin barrera en servidores de base de datos de 32 bits y 64 bits que

ejecutan el mismo sistema operativo.

Tabla 27. Soporte para rutinas externas de 32 y de 64 bits

Ancho de bits de la rutina Servidor de 32 bits Servidor de 64 bits

Procedimiento con barrera de 32 bits

o UDF

Soportado Soportado

Procedimiento con barrera de 64 bits

o UDF

No soportado (4) Soportado

Procedimiento sin barrera de 32 bits

o UDF

Soportado Soportado (2)

Procedimiento sin barrera de 64 bits

o UDF

No soportado (4) Soportado


Las notas a pie de página de la tabla anterior corresponden a:

v (1) Ejecutar una rutina de 32 bits en un servidor de 64 bits no es tan rápido

como ejecutar una rutina de 64 bits en un servidor de 64 bits.

v (2) Las rutinas de 32 bits deben crearse como FENCED y NOT THREADSAFE

para funcionar en un servidor de 64 bits.

v (3) No es posible invocar rutinas de 32 bits en servidores de base de datos de 64

bits Linux IA.

v (4) Las aplicaciones y las rutinas de 64 bits y no pueden ejecutarse en espacios

de direcciones de 32 bits.

Lo importante a tener en cuenta en la tabla es que los procedimientos sin barrera

de 32 bits no pueden ejecutarse en un servidor DB2 de 64 bits. Si debe desplegar

rutinas sin barrera de 32 bits en plataformas de 64 bits, elimine la cláusula NOT

FENCED de las sentencias CREATE para estas rutinas antes de catalogarlas.







v “Implementación de las rutinas externas” en Desarrollo de SQL y rutinas externas



Rendimiento de las rutinas con bibliotecas de 32 bits en

servidores de bases de datos de 64 bits

Es posible invocar rutinas con bibliotecas de rutinas de 32 bits en servidores de

bases de datos de DB2 de 64 bits. Sin embargo, su rendimiento no es tan bueno

como el de invocar una rutina de 64 bits en un servidor de 64 bits. La razón de la

disminución del rendimiento es que, antes de cada intento de ejecutar una rutina

de 32 bits en un servidor de 64 bits, primero se intenta invocarla como una

biblioteca de 64 bits. Si esto falla, entonces la biblioteca se invocará como una

biblioteca de 32 bits. Un intento fallido de invocar una biblioteca de 32 bits como si

fuera una biblioteca de 64 bits genera un mensaje de error (SQLCODE -444) en el

archivo db2diag.log.

Las clases de Java son independientes del número de bits. Solamente las máquinas

virtuales de Java (JVM) se clasifican como de 32 bits o de 64 bits. DB2 solo da

soporte al uso de JVM que tengan el mismo número de bits que la instancia en que

se están utilizando. Es decir, en una instancia de DB2 de 32 bits solamente puede

utilizarse una JVM de 32 bits y en una instancia de DB2 de 64 bits solamente

puede utilizarse una JVM de 64 bits. Esto garantiza el correcto funcionamiento de

las rutinas de Java y el mejor rendimiento posible.




Soporte para el tipo de datos XML en las rutinas externas

Los procedimientos y las funciones externas escritas en los siguientes lenguajes de

programación soportan parámetros y variables de tipo de datos XML:

v C

v C++

v COBOL

v Java

v Lenguajes .NET CLR

Las rutinas OLE y OLEDB externas no soportan parámetros de tipo de datos XML.

Los valores de tipo de datos XML se representan en el código de las rutinas

externas de la misma manera que los tipos de datos CLOB.

Cuando se declaran parámetros de tipo de datos XML para las rutinas externas, las

sentencias CREATE PROCEDURE y CREATE FUNCTION que se utilizarán para

crear las rutinas en la base de datos deben especificar que el tipo de datos XML se

debe almacenar en forma de tipo de datos CLOB. El tamaño del valor de CLOB

debe acercarse al tamaño del documento XML representado por el parámetro XML.

En la siguiente línea de código aparece una sentencia CREATE PROCEDURE de

un procedimiento externo implementado en el lenguaje de programación C con un

parámetro XML llamado parm1:

CREATE PROCEDURE myproc(IN parm1 XML AS CLOB(2M), IN parm2 VARCHAR(32000))

LANGUAGE C

FENCED

PARAMETER STYLE SQL

EXTERNAL NAME ’mylib!myproc’;

Hay que tener en cuenta consideraciones parecidas al crear funciones definidas por

usuario (UDF) externas, como se ve en el siguiente ejemplo:

CREATE FUNCTION myfunc (IN parm1 XML AS CLOB(2M))

RETURNS SMALLINT

LANGUAGE C

PARAMETER STYLE SQL

DETERMINISTIC

NOT FENCED

NULL CALL

NO SQL

NO EXTERNAL ACTION

EXTERNAL NAME ’mylib1!myfunc’

Los valores XML se serializan antes de pasarlos a rutinas externas.

En el código de las rutinas externas, los valores de los parámetros y variables XML

se acceden, establecen y modifican de la misma manera que en las aplicaciones de

bases de datos.



v “Encoding considerations for passing XML data in routine parameters” en XML

Guide


v “Parámetros y variables del tipo de datos XML en funciones de SQL” en


v “Soporte de XML y XQuery en procedimientos SQL” en Desarrollo de SQL y

rutinas externas


v “Especificación de un tipo de columna de datos” en Desarrollo de SQL y rutinas

externas


v “Tipos de datos SQL soportados para DB2 .NET Data Provider” en Desarrollo de


v “Tipos de datos de SQL soportados en rutinas DB2GENERAL” en Desarrollo de


v “Tipos de datos SQL soportados en rutinas Java” en Desarrollo de SQL y rutinas

externas

Restricciones de las rutinas externas

Se aplican las siguientes restricciones a las rutinas externas y deben tenerse en

cuenta a la hora de desarrollar o depurar rutinas externas:

Restricciones que se aplican a todas las rutinas externas::

v En las rutinas externas no se pueden crear hebras nuevas.

v Las API de nivel de conexión no se pueden llamar desde dentro de funciones o

métodos externos.

v Desde rutinas externas no es posible recibir entradas desde el teclado ni

visualizar salidas en la salida estándar. No utilice corrientes de entrada-salida

estándar. Por ejemplo:

– En código de rutinas Java externas, no emita los métodos

System.out.println().

– En código de rutinas C o C++ externas, no emita printf().

– En código de rutinas COBOL externas, no emita display

Aunque las rutinas externas no pueden visualizar datos en una salida estándar,

sí pueden incluir código que grabe datos en un archivo del sistema de archivos

del servidor de bases de datos.

Para las rutinas delimitadas (fenced) que se ejecutan en entornos UNIX, el

directorio de destino en que se debe crear el archivo, o el propio archivo, debe

tener los permisos adecuados, de forma que el propietario del archivo

sqllib/adm/.fenced pueda crearlo o grabar en él. Si se trata de rutinas no

delimitadas (not fenced), el propietario de la instancia debe tener permisos de

creación, lectura y grabación para el directorio en que se abra el archivo.

Nota: DB2 no intenta sincronizar la entrada externa ni la salida que realice una

rutina con transacciones propias de DB2. Así, por ejemplo, si una UDF

graba en un archivo durante una transacción y más tarde se retira dicha

transacción por cualquier motivo, no se realiza ningún intento de

descubrir ni deshacer las grabaciones efectuadas en el archivo.

v En rutinas externas no pueden ejecutarse sentencias o mandatos relacionados

con la conexión. Esta restricción es aplicable a las siguientes sentencias:

– BACKUP


– CONNECT

– CONNECT TO

– CONNECT RESET

– CREATE DATABASE

– DROP DATABASE

– FORWARD RECOVERY

– RESTOREv No es recomendable utilizar funciones del sistema operativo dentro de las

rutinas. El uso de estas funciones no está restringido, excepto en los casos

siguientes:

– No deben instalarse manejadores de señales definidos por el usuario para

rutinas externas. Si no se cumple con esta restricción, se pueden producir

anomalías inesperadas durante la ejecución de las rutinas externas,

terminaciones anormales de base de datos u otros problemas. La instalación

de manejadores de señales también puede interferir en el funcionamiento

de la JVM para las rutinas de Java.

– Las llamadas al sistema que terminan un proceso pueden terminar de forma

anómala uno de los procesos de DB2 y causar como consecuencia una

anomalía del sistema o de la aplicación de base de datos.

Otras llamadas al sistema también pueden ocasionar problemas si interfieren

en el funcionamiento normal del gestor de bases de datos DB2. Por ejemplo,

una función que intente descargar una biblioteca que contenga una función

definida por el usuario desde la memoria podría causar problemas graves.

Preste atención al programar y al probar las rutinas externas que contengan

llamadas al sistema.v Las rutinas externas no deben contener mandatos que terminen el proceso

actual. Una rutina externa siempre tiene que devolver el control al gestor de

bases de datos DB2 sin terminar el proceso actual.

v Las bibliotecas, clases o ensamblajes de rutinas externas no deben actualizarse

mientras la base de datos está activa, excepto en casos especiales. Si es necesario

realizar una actualización mientras el gestor de bases de datos de DB2 está

activo, y no es posible detener y volver a iniciar la instancia, cree la biblioteca,

clase o ensamblaje nuevo para la rutinas con uno diferente. A continuación,

utilice la sentencia ALTER para cambiar el valor de la cláusula EXTERNAL

NAME de la rutina externa de modo que haga referencia al nombre del archivo

de biblioteca, clase o ensamblaje nuevo.

v La variable de entorno DB2CKPTR no está disponible en las rutinas externas. Las

demás variables de entorno cuyos nombres empiezan por 'DB2' se capturan en el

momento en que se inicia el gestor de bases de datos y pueden utilizarse en las

rutinas externas.

v Algunas variables de entorno cuyos nombres no comienzan por 'DB2' no están

disponibles para las rutinas externas delimitadas (fenced). Por ejemplo, la

variable de entorno LIBPATH no puede utilizarse. Sin embargo, estas variables sí

están disponibles para las rutinas externas que no están delimitadas (not fenced).

v Los valores de variables de entorno establecidos una vez iniciado el gestor de

bases de datos de DB2 no están disponibles para las rutinas externas.

v Dentro de las rutinas externas, debe limitarse el uso de recursos protegidos,

recursos a los que únicamente puede acceder un proceso a la vez. Si han de

utilizarse, procure reducir la probabilidad de puntos muertos cuando dos rutinas

externas intenten acceder al recurso protegido. Si se producen puntos muertos

en dos o más rutinas, mientras se intenta acceder al recurso protegido, el gestor


de bases de datos de DB2 no será capaz de detectar o resolver la situación. Esto

ocasionará que los procesos de rutinas externas se queden colgados.

v La memoria para los parámetros de rutinas externas no debe asignarse

explícitamente en el servidor de bases de datos DB2. El gestor de bases de datos

de DB2 asigna automáticamente almacenamiento basándose en la declaración de

parámetros de la sentencia CREATE para la rutina. No modifique ningún

puntero del almacenamiento para los parámetros de las rutinas externas. Un

intento de cambiar un puntero por un puntero del almacenamiento creado

localmente puede tener como consecuencia fugas de memoria, corrupción de los

datos o terminaciones anormales.

v No utilice datos estáticos ni globales en las rutinas externas. DB2 no puede

garantizar que la memoria utilizada por las variables estáticas o globales no se

toque entre las invocaciones de rutinas externas. Para las UDF y los métodos,

puede emplear áreas reutilizables a fin de almacenar los valores que se utilizarán

entre las invocaciones.

v Los valores de todos los parámetros de SQL se colocan en el almacenamiento

intermedio. Esto significa que se realiza una copia del valor y se le pasa a la

rutina externa. Si se efectúan cambios en los parámetros de entrada de una

rutina externa, estos cambios no repercutirán en los valores de SQL ni en el

proceso. Sin embargo, si una rutina externa graba, en un parámetro de entrada o

de salida, más datos de los especificados en la sentencia CREATE, se habrá

corrompido la memoria y es posible que la rutina termine anormalmente.

Restricciones que se aplican solamente a los procedimientos externos:

v Cuando se devuelvan conjuntos de resultados desde procedimientos

almacenados anidados, podrá abrir un cursor con el mismo nombre en varios

niveles de anidamiento. No obstante, las aplicaciones anteriores a la versión 8

sólo podrán acceder al primer conjunto de resultados que se haya abierto. Esta

restricción no se aplica a los cursores abiertos con un nivel de paquete diferente.

Restricciones que se aplican solamente a las funciones externas:

v Las funciones externas no pueden devolver conjuntos de resultados. Todos los

cursores abiertos dentro de una función externa deben estar cerrados en el

momento en que se complete la invocación a la llamada final de la función.

v Las asignaciones dinámicas de memoria en una rutinas externa deben liberarse

antes de que la rutina externa devuelva el control. De lo contrario, se producirán

fugas de memoria y constante aumento del consumo de memoria de un proceso

de DB2 puede tener como consecuencia que el sistema de bases de datos se

quede sin memoria.

Para las funciones definidas por el usuario externas y los métodos externos,

pueden utilizarse áreas reutilizables para asignar la memoria dinámica necesaria

para la invocación de múltiples funciones. Si se utilizan áreas reutilizables de

este modo, especifique el atributo FINAL CALL en las sentencias CREATE

FUNCTION o CREATE METHOD. Así se garantiza que la memoria asignada se

liberará antes de que la rutina devuelva el control.



v “Manejo de tipos de datos de SQL en rutinas C y C++” en la página 334


v “Tipos de datos de SQL soportados en la automatización de OLE” en Desarrollo

de SQL y rutinas externas


v “Tipos de datos SQL soportados en OLE DB” en Desarrollo de SQL y rutinas

externas

v “Correlaciones de tipos de datos entre DB2 y OLE DB” en Desarrollo de

aplicaciones ADO.NET y OLE DB




v “Sentencia ALTER METHOD” en Consulta de SQL, Volumen 2


v “Sentencia CALL” en Consulta de SQL, Volumen 2




Creación de rutinas externas

Las rutinas externas, incluidos procedimientos y funciones, se crean de forma

parecida a las rutinas con otras implementaciones, aunque algunos pasos

adicionales necesarios porque la implementación de la rutina requiere la

codificación, compilación y despliegue del código fuente.

Elegirá implementar una rutina externa si:

v Desea encapsular lógica compleja en una rutina que acceda a la base de datos o

que realice una acción fuera de la base de datos.

v Necesita que la lógica encapsulada se invoque desde cualquiera de estos

elementos: diversas aplicaciones, el CLP, otra rutina (procedimiento, función

(UDF) o método) o un activador.

v Se siente más cómodo al codificar esta lógica en un lenguaje de programación en

lugar de utilizar sentencias de SQL y SQL PL.

v Necesita la lógica de rutina para realizar operaciones externas a la base de datos,

tales como escribir o leer un archivo del servidor de base de datos, la ejecución

de otra aplicación, o lógica que no puede representarse con sentencias de SQL y

SQL PL.

Requisitos previos:

v Conocimiento de la implementación de rutinas externas. Para obtener

información sobre las rutinas externas en general, consulte el tema:

– “Rutinas externas” en la página 275

– “Creación de rutinas externas” en la página 297v Debe instalarse el Cliente DB2.

v El servidor de bases de datos debe ejecutar un sistema operativo que dé soporte

a los compiladores del lenguaje de programación de la implementación elegida y

al software de desarrollo.

v Los compiladores necesarios y el soporte de ejecución para el lenguaje de

programación elegido deben estar instalados en el servidor de base de datos

v Autorización para ejecutar la sentencia CREATE PROCEDURE, CREATE

FUNCTION o CREATE METHOD.

Restricciones:

Para obtener una lista de las restricciones asociadas con rutinas externas, consulte:



Procedimiento:

1. Codifique la lógica de la rutina en el lenguaje de programación elegido.

v Para obtener información general sobre rutinas externas, características de las

rutinas y la implementación de características de las rutinas, consulte los

temas a los que se hace referencia en la sección Requisitos previos.

v Utilice o importe los archivos de cabecera necesarios para dar soporte a la

ejecución de sentencias de SQL.

v Declare las variables y los parámetros correctamente utilizando tipos de

datos del lenguaje de programación que se correlacionen con tipos de datos

de SQL de DB2.2. Los parámetros deben declararse de acuerdo con el formato requerido por el

estilo de parámetro para el lenguaje de programación elegido. Si desea más

información sobre los parámetros y las declaraciones de prototipo, consulte:

v “Estilos de parámetros de rutinas externas” en la página 2983. Construya el código en una biblioteca o archivo de clase.

4. Copie la biblioteca o archivo de clase en el directorio de función DB2 en el

servidor de base de datos. Es recomendable almacenar ensamblajes o

bibliotecas asociadas con rutinas de DB2 en el directorio de función. Para

conocer más acerca del directorio de función, consulte la cláusula EXTERNAL

de una de las sentencias siguientes: CREATE PROCEDURE o CREATE

FUNCTION.

Puede copiar el ensamblaje en otro directorio del servidor si lo desea, pero,

para invocar satisfactoriamente la rutina, debe anotar el nombre de vía de

acceso completamente calificado del ensamblaje porque lo necesitará en el paso

siguiente.

5. Ejecute de forma dinámica o estática la sentencia CREATE de lenguaje SQL

correspondiente para el tipo de rutina: CREATE PROCEDURE o CREATE

FUNCTION.

v Especifique la cláusula LANGUAGE con el valor adecuado correspondiente a la

API o lenguaje de programación elegido. Ejemplos: CLR, C, JAVA.

v Especifique la cláusula PARAMETER STYLE con el nombre del estilo de

parámetros soportado que se ha implementado en el código de la rutina.

v Especifique la cláusula EXTERNAL con el nombre del archivo de biblioteca,

clase o ensamblaje que se ha de asociar a la rutina utilizando uno de los

valores siguientes:

– el nombre de vía de acceso calificado al completo del archivo de

biblioteca, clase o ensamblaje de la rutina.

– el nombre de vía de acceso relativa del archivo de biblioteca, clase o

ensamblaje de la rutina con relación al directorio de función.Por omisión, DB2 buscará el archivo de biblioteca, clase o ensamblaje por el

nombre en el directorio de función, a menos que se especifique un nombre

de vía de acceso completamente calificado o relativo para el archivo en la

cláusula EXTERNAL.

v Especifique DYNAMIC RESULT SETS con un valor numérico si la rutina es

un procedimiento y ha de devolver uno o varios conjunto de resultados al

llamador.

v Especifique las demás cláusulas necesarias para caracterizar la rutina.

Para invocar la rutina externa, consulte Invocación de la rutina







v “Invocación de rutinas” en Desarrollo de SQL y rutinas externas


Rutinas C y C++

Rutinas C y C++

Las rutinas C y C++ son rutinas externas que se crean ejecutando una sentencia

CREATE PROCEDURE, CREATE FUNCTION o CREATE METHOD, que haga

referencia a una biblioteca creada a partir del código fuente C o C++ como su

cuerpo de código externo.

Las rutinas C y C++ pueden ejecutar opcionalmente sentencias de SQL incluyendo

sentencias de SQL incorporado.

Los siguientes términos son importantes en el contexto de las rutinas C y C++:

Sentencia CREATE

La sentencia CREATE del lenguaje SQL utilizada para crear la rutina en la

base de datos.

Código fuente del cuerpo de la rutina

El archivo de código fuente que contiene la implementación de la rutina C

o C++ que corresponde a la especificación de la cláusula EXTERNAL de la

sentencia CREATE.

Precompilador

El programa de utilidad de DB2 que preanaliza la implementación del

código fuente de la rutina para validar las sentencias de SQL contenidas en

el código y genera un paquete.

Compilador

El software específico del lenguaje de programación necesario para

compilar y enlazar la implementación del código fuente.

Paquete

El archivo que contiene la información de vía de acceso de tiempo de

ejecución que utilizará DB2 en el momento de la ejecución de la rutina

para ejecutar las sentencias de SQL contenidas en la implementación del

código de la rutina.

Biblioteca de la rutina

Un archivo que contiene el formato compilado del código fuente de la

rutina. En Windows a veces se denomina una DLL, porque estos archivos

tienen la extensión de archivo .dll.

Antes de desarrollar una rutina C o C++, es importante comprender los conceptos

básicos de las rutinas y las características exclusivas y específicas de las rutinas C y

C++. También es importante comprender la API de SQL incorporado y los

conceptos básicos sobre el desarrollo de aplicaciones de SQL incorporado. Para

obtener más información sobre estos temas, consulte los siguientes apartados:


v Rutinas externas

v SQL incorporado

v Archivos de inclusión para rutinas C y C++

v parámetros en rutinas C y C++

v Restricciones de rutinas C y C++

El desarrollo de rutinas C o C++ incluye seguir una serie de instrucciones paso a

paso y consultar ejemplos de rutinas C o C++. Consulte:

v Creación de rutinas C y C++

v Ejemplos de procedimientos C

v Ejemplos de funciones definidas por el usuario C


v “Herramientas para el desarrollo de rutinas C y C++” en la página 316







v “Diseño de rutinas C y C++” en la página 316

Soporte para el desarrollo de rutinas externas en C

Para desarrollar rutinas externas en C debe utilizar compiladores y software de

desarrollo soportados.

Todos los compiladores y el software de desarrollo soportados para el desarrollo

de aplicaciones de bases de datos DB2 en C se puede utilizar para el desarrollo de

rutinas externas en C.


v “Rutinas C y C++” en la página 314




v “Soporte para el desarrollo de aplicaciones de bases de datos en C” en Iniciación

al desarrollo de aplicaciones de bases de datos



datos

Soporte para el desarrollo de rutinas externas en C++

Para desarrollar rutinas externas en C++ debe utilizar compiladores y software de

desarrollo soportados.


Todos los compiladores y el software de desarrollo soportados para el desarrollo

de aplicaciones de bases de datos DB2 en C se pueden utilizar para el desarrollo

de rutinas externas en C++.






v “Soporte para el desarrollo de aplicaciones de bases de datos en C++” en




datos

Herramientas para el desarrollo de rutinas C y C++

Las herramientas soportadas para las rutinas C y C++ son las mismas que las

soportadas para aplicaciones C y C++ de SQL incorporado.

No hay entornos de desarrollo de DB2 ni herramientas gráficas de interfaz de

usuario para desarrollar, depurar o desplegar aplicaciones o rutinas de SQL

incorporado.

Las siguientes interfaces de línea de mandatos se suelen utilizar para desarrollar,

depurar y desplegar aplicaciones y rutinas de SQL incorporado:

v Procesador de línea de mandatos de DB2

v Ventana de mandatos de DB2

Estas interfaces dan soporte a la ejecución de las sentencias de SQL necesarias para

crear rutinas en una base de datos. El mandato PREPARE y el mandato BIND

necesarios para crear rutinas C y C++ que contienen SQL incorporado también se

puede emitir desde estas interfaces.



v “Procesador de línea de mandatos (CLP) de DB2” en Desarrollo de SQL y rutinas

externas

v “Herramientas para desarrollar rutinas” en Desarrollo de SQL y rutinas externas



Diseño de rutinas C y C++

Diseño de rutinas C y C++

El diseño de rutinas C y C++ es una tarea que debe preceder a la creación de

dichas rutinas. El diseño de rutinas C y C++ suele estar relacionado con el diseño

de rutinas externas implementadas en otros lenguajes de programación y con el

diseño de aplicaciones de SQL incorporado.

Requisitos previos:


v Conocimientos generales sobre rutinas externas

v Experiencia con la programación de C o C++

v Opcional: Conocimientos sobre, y experiencia con, el desarrollo de aplicaciones

CLI y SQL incorporado (si la rutina va a ejecutar sentencias de SQL)

Los temas siguientes proporcionan parte de la información necesaria sobre

requisitos previos.

Para obtener más información sobre las funciones y usos de rutinas externas:

v Consulte el tema, Rutinas externas

Para obtener más información sobre las características de la API de SQL:

v Consulte el tema, SQL incorporado

Procedimiento:

Con el conocimiento de los requisitos previos, el diseño de rutinas de SQL

incorporado consiste principalmente en conocer las funciones y características

exclusivas de las rutinas C y C++:

v “Archivo de inclusión necesario para el desarrollo de rutinas C y C++

(sqludf.h)” en la página 318


v “Estilo de parámetros SQL en procedimientos C y C++” en la página 320

v “Estilo de parámetros SQL en funciones C y C++” en la página 324


v “Variables gráficas del lenguaje principal en rutinas C y C++” en la página 356

v “Devolución de conjuntos de resultados desde procedimientos C y C++” en la

página 358

v “Decoración de tipos de C++” en la página 356


Después de conocer las características de C y C++, puede interesarle:



v “Implementación de las rutinas externas” en Desarrollo de SQL y rutinas externas

v “Introducción a SQL incorporado” en la página 3






página 358

v “Decoración de tipos de C++” en la página 356


v “Consideraciones sobre la precompilación y vinculación para rutinas de SQL









Archivo de inclusión necesario para el desarrollo de rutinas C y

C++ (sqludf.h)

El archivo de inclusión sqludf.h contiene estructuras, definiciones y valores que

son de utilidad al escribir las rutinas. Aunque el nombre de este archivo incluye

’udf’, (por razones históricas) también sirve para los procedimientos almacenados y

los métodos. Cuando se compile una rutina, se tendrá que hacer referencia al

directorio que contiene este archivo. Este directorio es sqllib/include.

El archivo de inclusión sqludf.h se autodescribe. A continuación puede ver un

breve resumen de su contenido:

1. Definiciones de estructuras para argumentos que están representados por

estructuras en C ó C++:

v Argumentos y resultado VARCHAR FOR BIT DATA

v Argumentos y resultado LONG VARCHAR (con o sin FOR BIT DATA)

v Argumentos y resultado LONG VARGRAPHIC

v Argumentos y resultado SQL de todos los tipos de LOB

v El área reutilizable

v La estructura dbinfo2. Las definiciones del tipo de lenguaje C para todos los tipos de datos SQL, para

utilizarlos en la definición de argumentos de rutinas correspondientes a

argumentos y resultado de SQL que tienen los tipos de datos. Se trata de las

definiciones que tienen por nombre SQLUDF_x y SQLUDF_x_FBD, donde x es

un nombre de tipo de datos de SQL y FBD representa FOR BIT DATA.

También se incluye un tipo de lenguaje C para un argumento o resultado

definido con la cláusula AS LOCATOR. Esto sólo es aplicable a las UDF y los

métodos.

3. Definición de tipos de lenguaje C para argumentos del área-reutilizable y del

tipo-llamada, con una definición de tipo enum del argumento tipo-llamada.

4. Macros para definir los argumentos estándar de cola, tanto con como sin la

inclusión de argumentos de área-reutilizable y tipo-llamada. Esto corresponde a la

presencia y ausencia de las palabras clave SCRATCHPAD y FINAL CALL en la

definición de la función. Son los argumentos de invocación de UDF estado-SQL,

nombre-función, nombre-específico, mensaje-diagnóstico, área-reutilizable y

tipo-llamada. También se incluyen las definiciones para hacer referencia a estas

construcciones y los diversos valores de SQLSTATE válidos.

5. Macros para comprobar si los argumentos de SQL son nulos.

Existe un archivo de inclusión correspondiente para COBOL: sqludf.cbl. Este

archivo sólo incluye definiciones para las estructuras de área reutilizable y dbinfo.








v “Tipos de datos de SQL soportados en rutinas C y C++” en la página 331

Parámetros de rutinas C y C++

Parámetros de rutinas C y C++: La declaración de parámetros de las rutinas C y

C++ debe cumplir con los requisitos de uno de los estilos de parámetros y del tipo

de programa que se soportan. Si la rutina ha de emplear un área reutilizable o la

estructura dbinfo o ha de tener la interfaz de parámetros PROGRAM TYPE MAIN,

existen detalles adicionales a considerar, incluidos:

v Estilos de parámetros para rutinas C y C++



v “Indicadores nulos de parámetros en rutinas C y C++” en la página 320

v “Paso de parámetros por valor o por referencia en rutinas C y C++” en la página

326

v “No se necesitan parámetros para conjuntos de resultados de procedimientos C


v Estructura dbinfo como parámetro de rutina C o C++

v “Área reutilizable como parámetro de función C o C++” en la página 329

v Tipo de programa MAIN soportado para procedimientos C y C++

Es muy importante implementar la interfaz de parámetros para rutinas C y C++

correctamente. Esto puede realizarse fácilmente teniendo cuidado para asegurarse

de que se eligen e implementan el estilo de parámetros y los tipos de datos

correctos de acuerdo con la especificación.





Estilos de parámetros soportados para rutinas C y C++: Los siguientes estilos de

parámetros reciben soporte para rutinas C y C++:

v SQL (soportado para procedimientos y funciones; recomendado)

v GENERAL (Soportado para procedimientos)

v GENERAL WITH NULLS (Soportado para procedimientos)

Se recomienda utilizar el estilo de parámetros SQL para todas las rutinas C y C++.

Este estilo de parámetros da soporte a valores NULL, proporciona una interfaz

estándar para errores de informe, así como áreas reutilizables de soporte y tipos de

llamadas.

Para especificar el estilo de parámetros que se van a utilizar para una rutina, debe

especificar la cláusula PARAMETER STYLE de la sentencia CREATE para dicha

rutina en el momento de creación de la rutina.

El estilo de parámetros se debe reflejar adecuadamente en la implementación del

código de la rutina C o C++.


Para obtener más información sobre estos estilos de parámetros, consulte: ″Sintaxis

para pasar parámetros a rutinas C y C++″.


v “Estructura dbinfo como parámetros de rutinas C o C++” en la página 327





326



Indicadores nulos de parámetros en rutinas C y C++: Si el estilo de parámetros

elegido para una rutina C o C++ (procedimiento o función) necesita que se

especifique un parámetro de indicador nulo para cada uno de los parámetros SQL,

como en el caso del estilo de parámetros SQL, los indicadores nulos se tienen que

pasar como parámetros del tipo de datos SQLUDF_NULLIND. Para el estilo de

parámetros GENERAL WITH NULLS, se deben pasar como una matriz de tipo

SQUDF_NULLIND. Este tipo de datos se define en el archivo de inclusión de una

rutina y aplicación de SQL incorporado: sqludf.h.

Los parámetros de indicadores nulos indican si el valor del parámetro

correspondiente es equivalente a NULL en SQL o si tiene un valor literal. Si el

valor del indicador nulo para un parámetro es 0, significa que el valor del

parámetro no es nulo. Si el valor del indicador nulo de un parámetro es -1, se

considera que el parámetro tiene un valor equivalente al valor de SQL NULL.

Cuando se utilizan indicadores nulos, es importante incluir código dentro de la

rutina que:

v Compruebe los valores de los indicadores nulos para ver los parámetros de

entrada antes de utilizarlos.

v Establezca valores de indicadores nulos para parámetros de salida antes de que

la rutina devuelva un valor.

Para obtener más información sobre parámetros de SQL, consulte:



v “Estilos de parámetros soportados para rutinas C y C++” en la página 319

v “No se necesitan parámetros para conjuntos de resultados de procedimientos C




326


Estilo de parámetros SQL en procedimientos C y C++: Los procedimientos C y

C++ se deben crear utilizando la cláusula PARAMETER STYLE SQL en la sentencia

CREATE PROCEDURE. Los convenios de paso de parámetros de este estilo de

parámetros se deben implementar en la implantación del código del procedimiento

correspondiente.


La implementación de la signatura SQL PARAMETER STYLE de C y C++

necesaria para procedimientos sigue este formato:

SQL_API_RC SQL_API_FN nombre-función ( argumentos-SQL,

SQL-argument-inds,

sqlstate,

nombre-rutina,

nombre-específico,

mensaje-diagnóstico )

SQL_API_RC SQL_API_FN

SQL_API_RC y SQL_API_FN son macros que especifican el tipo de retorno y el

convenio de llamada para un procedimiento C o C++, los cuales pueden

ser distintos según los sistemas operativos soportados. El uso de estas

macros es obligatorio para rutinas C y C++. Las macros se declaran en el

archivo de inclusión de rutinas y aplicaciones de SQL incorporado

sqlsystm.h.

nombre-función

Nombre de la función C o C++ dentro del archivo del código. No es

necesario que este valor coincida con el nombre del procedimiento

especificado dentro de la sentencia CREATE PROCEDURE

correspondiente. Sin embargo, se debe especificar este valor, en

combinación con el nombre de la biblioteca, en la cláusula EXTERNAL

NAME para identificar el punto de entrada de función correcto dentro de

la biblioteca que se va a utilizar. En las rutinas C++, el compilador C++

aplica la decoración de tipos al nombre de punto de entrada. Hay que

especificar el nombre decorado con tipos en la cláusula EXTERNAL NAME

o bien se debe definir el punto de entrada como extern "C" en el código

del usuario. Debe exportar el nombre de la función de forma explícita.

argumentos-SQL

Los argumentos de C o C++ correspondientes al conjunto de parámetros

SQL especificados en la sentencia CREATE PROCEDURE. Los parámetros

de modalidad IN, OUT e INOUT se pasan mediante valores de puntero

individuales.

ind-argumentos-SQL

Indicadores de nulo C o C++ que corresponden al conjunto de parámetros

de SQL especificados en la sentencia CREATE PROCEDURE. Para cada

parámetro de modalidad IN, OUT e INOUT, debe existir un parámetro del

indicador de nulo asociado. Los indicadores de nulo se pueden pasar como

argumentos individuales de tipo SQLUDF_NULLIND, o como parte de

una sola matriz de indicadores de nulo definida como

SQLUDF_NULLIND*.

sqlstate Valor del parámetro de entrada y salida utilizado por la rutina para señalar

condiciones de aviso o error. Normalmente, este argumento se utiliza para

asignar un valor de SQLSTATE definido por el usuario correspondiente a

un error o aviso, que puede devolverse al llamador. Los valores SQLSTATE

con formato 38xxx, donde xxx representa cualquier valor numérico, están

disponibles para valores de error SQLSTATE definidos por el usuario. Los

valores con formato 01Hxx, donde xx representa cualquier valor numérico,

están disponibles para valores de avisos SQLSTATE definidos por el

usuario.

nombre-rutina

Valor del parámetro de entrada que contiene el nombre calificado de la

rutina. Este valor lo genera DB2 y lo pasa a la rutina en el formato

<nombre-esquema>.<nombre-rutina> donde <nombre-esquema> y

<nombre-rutina> corresponden respectivamente al valor de la columna


ROUTINESCHEMA y al valor de la columna ROUTINENAME

correspondientes a la rutina dentro de la vista de catálogo

SYSCAT.ROUTINES. Este valor puede resultar útil si múltiples definiciones

de rutina diferentes utilizan una única implementación de rutina. Cuando

el nombre de la definición de la rutina se ha pasado a la rutina, se podrá

ejecutar condicionalmente la lógica, dependiendo de qué definición se haya

utilizado. El nombre de la rutina puede ser útil cuando se formule la

información de diagnósticos, incluidos los mensajes de error, o cuando se

escriba en un archivo de anotaciones cronológicas.

nombre-específico

Valor del parámetro de entrada que contiene el nombre exclusivo

específico de la rutina. Este valor lo genera DB2 y lo pasa a la rutina. Este

valor se corresponde con el valor de la columna SPECIFICNAME

correspondiente a la rutina en la vista SYSCAT.ROUTINES. Puede resultar

tan útil como el nombre-rutina.

mensaje-diagnóstico

Valor del parámetro de salida opcionalmente utilizado por la rutina para

devolver el texto del mensaje a la aplicación o rutina que lo ha invocado.

Este parámetro está diseñado para ser utilizado como un complemento

para el argumento SQLSTATE. Se puede utilizar para asignar un mensaje

de error definido por el usuario que acompañe a un valor SQLSTATE

definido por el usuario, lo cual puede proporcionar información más

detallada sobre errores o avisos de diagnóstico al llamador de la rutina.

Nota: Para simplificar la escritura de signaturas de procedimientos C y C++,

puede utilizarse la definición de macro SQLUDF_TRAIL_ARGS definida en

sqludf.h, en lugar de utilizar argumentos individuales, en la signatura del

procedimiento para implementar los argumentos de tipos de datos que no

son SQL.

A continuación se muestra un ejemplo de una implementación de un

procedimiento C o C++ que acepta un solo parámetro de entrada y devuelve un

solo parámetro de salida y un conjunto de resultados:

/****************************************************************

Rutina: cstp

Objetivo: Devuelve un valor de parámetro de salida basado en un valor

de parámetro de entrada

Muestra cómo:

- definir un procedimiento utilizando PARAMETER STYLE SQL

- definir indicadores NULL para el parámetro

- ejecutar una sentencia de SQL

- definir un indicador NULL cuando el parámetro no es nulo

Parámetros:

IN: inParm

OUT: outParm

Cuando se define PARAMETER STYLE SQL para la rutina

(consulte el script de registro de rutina spcreate.db2),

además de los parámetros pasados durante la invocación,

los argumentos siguientes se pasan a la rutina en el

orden siguiente:

- un indicador de nulo para cada parámetro IN/INOUT/OUT,

ordenados de forma que coincidan con el orden de las

declaraciones de parámetros


- SQLSTATE que se debe devolver a DB2 (salida)

- nombre calificado de la rutina (entrada)

- nombre específico de la rutina (entrada)

- serie de diagnóstico de SQL para devolver un texto de

mensajes de error opcional a DB2 (salida)

Consulte más abajo las declaraciones de parámetros reales

para ver qué tipos de datos y tamaños se recomiendan.

SUGERENCIA DE CÓDIGO:

---------------------

En lugar de codificar los parámetros ’extra’:

sqlstate, nombre calificado de la rutina, nombre

específico de la rutina, mensaje de diagnóstico,

se puede utilizar un macro SQLUDF_TRAIL_ARGS.

Este macro se define en el archivo de inclusión sqludf.h de DB2

SUGERENCIA DE EJEMPLO:

----------------------

El siguiente ejemplo es equivalente al prototipo real

usado, que utiliza definiciones de macro incluidas

en sqludf.h. El formato implementado en realidad es

más simple y elimina las cuestiones sobre tipos de datos.

extern "C" SQL_API_RC SQL_API_FN OutLanguage(

sqlint16 *inParm,

double *outParm,

sqlint16 *inParmNullInd,

sqlint16 *outParmNullInd,

char sqlst[6],

char qualName[28],

char specName[19],

char diagMsg[71])

)

*****************************************************************/

extern "C" SQL_API_RC SQL_API_FN cstp ( sqlint16 *inParm,

double *outParm,

SQLUDF_NULLIND *inParmNullInd,

SQLUDF_NULLIND *outParmNullInd,

SQLUDF_TRAIL_ARGS )

{



sqlint16 sql_inParm;


sql_inParm = *inParm;

EXEC SQL DECLARE cur1 CURSOR FOR

SELECT value

FROM table01

WHERE index = :sql_inParm;

*outParm = (*inParm) + 1;

*outParmNullInd = 0;

EXEC SQL OPEN cur1;

return (0);

}

La sentencia CREATE PROCEDURE que corresponde a este procedimiento es la

siguiente:


CREATE PROCEDURE cproc( IN inParm INT, OUT outParm INT )

LANGUAGE c

PARAMETER STYLE sql

DYNAMIC RESULT SETS 1

FENCED

THREADSAFE

RETURNS NULL ON NULL INPUT

EXTERNAL NAME ’c_rtns!cstp’

La sentencia anterior supone que la implementación del procedimiento C o C++

está en un archivo de biblioteca denominado c_rtns y en una función denominada

cstp.

Estilo de parámetros SQL en funciones C y C++: Las funciones definidas por el

usuario C y C++ se deben crear utilizando la cláusula PARAMETER STYLE SQL

en la sentencia CREATE FUNCTION. Los convenios de paso de parámetros de este

estilo de parámetros se deben implementar en la implantación del código fuente

correspondiente. La implementación de la signatura SQL PARAMETER STYLE de

C y C++ necesaria para funciones definidas por el usuario sigue este formato:

SQL_API_RC SQL_API_FN nombre-función ( argumentos-SQL,

SQL-argument-inds,

SQLUDF_TRAIL_ARGS )

SQL_API_RC SQL_API_FN

SQL_API_RC y SQL_API_FN son macros que especifican el tipo de retorno y el

convenio de llamada para una función definida por el usuario C o C++, los

cuales pueden ser distintos según los sistemas operativos soportados. El

uso de estas macros es obligatorio para rutinas C y C++. Las macros se

declaran en el archivo de inclusión de rutinas y aplicaciones de SQL

incorporado sqlsystm.h.

nombre-función

Nombre de la función C o C++ dentro del archivo del código. No es

necesario que este valor coincida con el nombre de la función especificado

dentro de la sentencia CREATE FUNCTION correspondiente. Sin embargo,

se debe especificar este valor, en combinación con el nombre de la

biblioteca, en la cláusula EXTERNAL NAME para identificar el punto de

entrada de función correcto dentro de la biblioteca que se va a utilizar. En

las rutinas C++, el compilador C++ aplica la decoración de tipos al nombre

de punto de entrada. Se tiene que especificar el nombre decorado del tipo

en la cláusula EXTERNAL NAME o la declaración de la función dentro del

archivo del código fuente se tiene que preceder de extern "C", tal como se

muestra en el siguiente ejemplo: extern ″C″ SQL_API_RC SQL_API_FN

OutLanguage( char *, sqlint16 *, char *, char *, char *, char *);

argumentos-SQL

Los argumentos de C o C++ correspondientes al conjunto de parámetros

SQL especificados en la sentencia CREATE FUNCTION.

ind-argumentos-SQL

Para cada argumento-SQL, se necesita un parámetro de indicador nulo

para especificar si el valor del parámetro se tiene que interpretar dentro de

la implementación de la rutina como un valor NULL en SQL. Los

indicadores nulos se deben especificar con el tipo de datos

SQLUDF_NULLIND. Este tipo de datos se define en el archivo de

inclusión de rutinas de SQL incorporado sqludf.h.

SQLUDF_TRAIL_ARGS

Una macro definida en el archivo de inclusión de rutinas de SQL


incorporado sqludf.h que, una vez ampliada, define los argumentos

finales adicionales necesarios para obtener una signatura completa SQL de

estilo de parámetros. Se pueden utilizar dos macros:

SQLUDF_TRAIL_ARGS y SQLUDF_TRAIL_ARGS_ALL.

SQLUDF_TRAIL_ARGS, una vez ampliada, tal como está definida en

sqludf.h, equivale a la adición de los siguientes argumentos de rutina:

SQLUDF_CHAR *sqlState,

SQLUDF_CHAR qualName,

SQLUDF_CHAR specName,

SQLUDF_CHAR *sqlMessageText,

En general estos argumentos no son necesarios ni se suelen utilizar como

parte de la lógica de función definida por el usuario. Representan el valor

de SQLSTATE de salida que se tiene que pasar al que ha invocado la

función, el nombre de función calificado al completo de entrada, el nombre

específico de la función de entrada y el texto del mensaje de salida que se

tiene que devolver con SQLSTATE. SQLUDF_TRAIL_ARGS, una vez

ampliada, tal como está definida en sqludf.h, equivale a la adición de los

siguientes argumentos de rutina:

SQLUDF_CHAR qualName,

SQLUDF_CHAR specName,

SQLUDF_CHAR sqlMessageText,

SQLUDF_SCRAT *scratchpad

SQLUDF_CALLT *callType

Si la sentencia UDF CREATE incluye la cláusula SCRATCHPAD o la

cláusula FINAL CALL, se debe utilizar la macro SQLUDF_TAIL_ARGS_ALL.

Además de los argumentos proporcionados con SQLUDF_TRAIL_ARGS, esta

macro también contiene punteros a una estructura de área reutilizable y a

un valor de tipo de llamada.

A continuación se muestra un ejemplo de una UDF C o C++ que devuelve en un

parámetro de salida el valor del producto de sus dos valores de parámetros de

entrada:

SQL_API_RC SQL_API_FN product ( SQLUDF_DOUBLE *in1,

SQLUDF_DOUBLE *in2,

SQLUDF_DOUBLE *outProduct,

SQLUDF_NULLIND *in1NullInd,

SQLUDF_NULLIND *in2NullInd,

SQLUDF_NULLIND *productNullInd,

SQLUDF_TRAIL_ARGS )

{

/* comprobar que los valores de los parámetros de entrada no sean nulos

comprobando los valores de indicadores nulos correspondientes

0 : indica que el valor del parámetro no es NULL

-1 : indica que el valor del parámetro es NULL

Si los valores no son NULL, calcular el producto.

Si los valores son NULL, devolver un valor de salida NULL. */

if ((*in1NullInd != -1) &&

*in2NullInd != -1))

{

*outProduct = (*in1) * (*in2);

*productNullInd = 0;

}

else

{


*productNullInd = -1;

}

return (0);

}

La sentencia CREATE FUNCTION correspondiente que se puede utilizar para crear

esta UDF podría ser la siguiente:

CREATE FUNCTION product( in1 DOUBLE, in2 DOUBLE )

RETURNS DOUBLE

LANGUAGE C

PARAMETER STYLE SQL

NO SQL

FENCED THREADSAFE

DETERMINISTIC

RETURNS NULL ON NULL INPUT

NO EXTERNAL ACTION

EXTERNAL NAME ’c_rtns!product’

En la sentencia SQL anterior se da por supuesto que la función C o C++ está en un

archivo de biblioteca en el directorio de función denominado c_rtns.

Paso de parámetros por valor o por referencia en rutinas C y C++: Para rutinas

C y C++, los valores de los parámetros se deben pasar siempre por referencia a las

rutinas utilizando punteros. Ésto es necesario para parámetros sólo de entrada, de

entrada-salida y de salida. por referencia.

Los parámetros del indicador de nulo también se deben pasar por referencia a las

rutinas utilizando punteros.

Nota: DB2 controla la asignación de memoria para todos los parámetros y

mantiene las referencias de C o C++ a todos los parámetros pasados a una

rutina o salidos de ella. No es necesario asignar o liberar la memoria

asociada a parámetros de rutinas e indicadores de nulo.

No se necesitan parámetros para conjuntos de resultados de procedimientos C y

C++: No se necesita ningún parámetro en la signatura de la sentencia CREATE

PROCEDURE para un procedimiento o en la implementación de procedimiento

asociado para devolver un conjunto de resultados al llamador.

Los conjuntos de resultados devueltos de procedimientos C, se devuelven

utilizando cursores.

Si desea más información sobre la devolución de conjuntos de resultados desde

procedimientos LANGUAGE C, consulte:


página 358



v “Indicadores nulos de parámetros en rutinas C y C++” en la página 320

v “Estilos de parámetros soportados para rutinas C y C++” en la página 319





v “Devolución de conjuntos de resultados procedentes de procedimientos .NET de

CLR” en Desarrollo de SQL y rutinas externas

Estructura dbinfo como parámetros de rutinas C o C++: La estructura dbinfo es

una estructura que contiene información sobre bases de datos y rutinas, que puede

pasarse a la implementación de la rutina, y recibirse de ésta, como un argumento

extra, sólo si la cláusula DBINFO está incluida en la sentencia CREATE para dicha

rutina.

La estructura dbinfo recibe soporte en rutinas LANGUAGE C a través del uso de

la estructura sqludf_dbinfo. Esta estructura C está definida en el archivo de

inclusión de DB2 sqludf.h situado en el directorio sqllib\include.

La estructura sqludf_dbinfo se define del modo siguiente:

SQL_STRUCTURE sqludf_dbinfo

{

unsigned short dbnamelen; /* Longitud del nombre de base datos */

unsigned char dbname[SQLUDF_MAX_IDENT_LEN]; /* Nombre de la base de datos */

unsigned short authidlen; /* Longitud del ID de autorización */

unsigned char authid[SQLUDF_MAX_IDENT_LEN]; /* ID de autorización */

union db_cdpg codepg; /* Página de códigos de base datos */

unsigned short tbschemalen; /* Long. del nombre esquema de tabla */

unsigned char tbschema[SQLUDF_MAX_IDENT_LEN]; /* Nombre del esquema de tabla */

unsigned short tbnamelen; /* Longitud del nombre de la tabla */

unsigned char tbname[SQLUDF_MAX_IDENT_LEN]; /* Nombre de la tabla */

unsigned short colnamelen; /* Longitud del nombre de columna */

unsigned char colname[SQLUDF_MAX_IDENT_LEN]; /* Nombre de columna */

unsigned char ver_rel[SQLUDF_SH_IDENT_LEN]; /* Versión/release de base de datos */

unsigned char resd0[2]; /* Alineación */

sqluint32 platform; /* Plataforma */

unsigned short numtfcol; /* # de entradas de la matriz de */

/* la lista de columnas TF */

unsigned char resd1[2]; /* Reservado */

sqluint32 procid; /* ID de procedimiento actual */


unsigned short *tfcolumn; /* Se debe asignar la Tfcolumn */

/* dinámicamente si se define */

/* una función de tabla; */

/* si no, un puntero a Null */

char *appl_id; /* Identificador de la aplicación */

sqluint32 dbpartitionnum; /* Número de partición de la base de */

/* datos donde se ejecutó la rutina */


};

Aunque no todos los campos de la estructura dbinfo puedan ser útiles durante de

una rutina, varios de los valores en los campos de esta estructura serán de utilidad

al formular la información sobre los mensajes de errores de diagnóstico. Por

ejemplo, si ocurre un error dentro de una rutina, puede que resulte útil devolver el

nombre de la base de datos, la longitud del nombre de la base de datos, la página

de códigos de la base de datos, el ID de la autorización actual y la longitud del ID

de la autorización actual.

Para hacer referencia a la estructura sqludf_dbinfo en una implementación de la

rutina LANGUAGE C:

v Añada la cláusula DBINFO a la sentencia CREATE que define la rutina.

v Incluya el archivo de cabecera sqludf.h al principio del archivo que contenga la

implementación de la rutina.

v Añada un parámetro de tipo sqludf_dbinfo a la signatura de la rutina en la

posición especificada por el estilo de parámetros utilizado.


A continuación figura un ejemplo de un procedimiento C con PARAMETER STYLE

GENERAL que muestra el uso de la estructura dbinfo. A continuación se

proporciona la sentencia CREATE PROCEDURE para el procedimiento. Observe

que según se especifica en la cláusula EXTERNAL NAME, la implementación del

procedimiento está situada en un archivo de biblioteca denominado spserver que

contiene una función C denominada DbinfoExample:

CREATE PROCEDURE DBINFO_EXAMPLE (IN job CHAR(8),

OUT salary DOUBLE,

OUT dbname CHAR(128),

OUT dbversion CHAR(8),

OUT errorcode INTEGER)


LANGUAGE C

PARAMETER STYLE GENERAL

DBINFO

FENCED NOT THREADSAFE

READS SQL DATA

PROGRAM TYPE SUB

EXTERNAL NAME ’spserver!DbinfoExample’@

A continuación figura la implementación del procedimiento C correspondiente a la

definición del procedimiento:

/***************************************************************

Rutina: DbinfoExample

IN: inJob - un tipo de trabajo, utilizado en un predicado

SELECT

OUT: salary - salario medio de los empleados con trabajo

job injob

dbname - nombre de base de datos recuperada de DBINFO

dbversion - versión de base de datos recuperada de DBINFO

outSqlError - sqlcode de error emitido (si los hay)

sqludf_dbinfo - puntero a la estructura DBINFO

Objetivo: La rutina toma un tipo de trabajo y devuelve el

salario medio de todos los empleados con ese trabajo,

así como información sobre la base de datos (nombre,

versión de base de datos). La información de la base

de datos se recupera desde el objeto de dbinfo.

Muestra cómo:

- definir parámetros IN/OUT en PARAMETER STYLE GENERAL

- declarar un puntero de parámetro a la estructura dbinfo

- recuperar valores de la estructura dbinfo

*****************************************************************/

SQL_API_RC SQL_API_FN DbinfoExample(char inJob[9],

double *salary,

char dbname[129],

char dbversion[9],

sqlint32 *outSqlError,

struct sqludf_dbinfo * dbinfo

)

{

/* Declare una SQLCA local */

struct sqlca sqlca;

EXEC SQL WHENEVER SQLERROR GOTO return_error;

/* Sección de declaración de las variables de lenguaje principal de SQL */

/* Cada nombre de variable del lenguaje principal debe ser exclusivo dentro

de un archivo de código, si no el precompilador emitirá el error SQL0307 */


char dbinfo_injob[9];

double dbinfo_outsalary;

sqlint16 dbinfo_outsalaryind;



/* Inicializar parámetros de salida - establecer series en NULL */

memset(dbname, ’\0’, 129);

memset(dbversion, ’\0’, 9);

*outSqlError = 0;

/* Copie parámetro de entrada en la variable del lenguaje local */

strcpy(dbinfo_injob, inJob);

EXEC SQL SELECT AVG(salary) INTO:dbinfo_outsalary

FROM employee

WHERE job =:dbinfo_injob;

*salary = dbinfo_outsalary;

/* Copie los valores de la estructura DBINFO en los parámetros de salida.

Las series deben terminar de forma explícita en nulo.

La información, como por ejemplo, el nombre de la base de datos y la

versión del producto de la base de datos, puede encontrarse en la

estructura DBINFO, así como otros campos de información. */

strncpy(dbname, (char *)(dbinfo->dbname), dbinfo->dbnamelen);

dbname[dbinfo->dbnamelen] = ’\0’;

strncpy(dbversion, (char *)(dbinfo->ver_rel), 8);

dbversion[8] = ’\0’;

return 0;

/* Copie el SQLCODE en el parámetro OUT si se produce un error SQL */

return_error:

{

*outSqlError = SQLCODE;

EXEC SQL WHENEVER SQLERROR CONTINUE;

return 0;

}

} /* DbinfoExample function */

Área reutilizable como parámetro de función C o C++: La estructura del área

reutilizable, utilizada para almacenar valores de UDF entre invocaciones para cada

valor de entrada de UDF, recibe soporte en rutinas C y C++ mediante el uso de la

estructura sqludf_scrat. Esta estructura C está definida en el archivo de inclusión

de DB2 sqludf.h.

Para hacer referencia a la estructura sqludf_scrat, incluya el archivo de cabecera

sqludf.h al principio del archivo que contiene la implementación de la función C o

C++ y utilice la macro SQLUDF_TRAIL_ARGS_ALL dentro de la signatura de la

implementación de la rutina.

En el siguiente ejemplo se hace una demostración de la implementación de una

función escalar C que incluye un parámetro de tipo SQLUDF_TRAIL_ARGS_ALL:

#ifdef __cplusplus

extern "C"

#endif

void SQL_API_FN ScratchpadScUDF(SQLUDF_INTEGER *outCounter,

SQLUDF_SMALLINT *counterNullInd,

SQLUDF_TRAIL_ARGS_ALL)

{

struct scalar_scratchpad_data *pScratData;

/* SQLUDF_CALLT y SQLUDF_SCRAT son */

/* partes de SQLUDF_TRAIL_ARGS_ALL */


pScratData = (struct scalar_scratchpad_data *)SQLUDF_SCRAT->data;

switch (SQLUDF_CALLT)

{

case SQLUDF_FIRST_CALL:

pScratData->counter = 1;

break;

case SQLUDF_NORMAL_CALL:

pScratData->counter = pScratData->counter + 1;

break;

case SQLUDF_FINAL_CALL:

break;

}

*outCounter = pScratData->counter;

*counterNullInd = 0;

} /* ScratchpadScUDF */

La macro SQLUDF_TRAIL_ARGS_ALL se expande para definir otros valores de

parámetros, incluido uno que se llama SQLUDF_SCRAT y define un parámetro de

memoria intermedia que se debe usar a modo de área reutilizable. Cuando se

invoca la función escalar para un conjunto de valores, cada vez que se invoca la

función escalar, la memoria intermedia se pasa como parámetro a la función. La

memoria intermedia puede servir para acceder a ella

El valor de la macro SQLUDF_TRAIL_ARGS_ALL también define otro parámetro,

SQLUDF_CALLT. Este parámetro sirve para indicar un valor de tipo de llamada.

Los valores de tipo de llamada pueden servir para identificar si una función se

invoca por primera vez para un conjunto de valores, por última vez o en un

momento intermedio del proceso.

Soporte de MAIN de tipo de programa para procedimientos C y C++: Aunque

generalmente se recomienda el valor por omisión SUB de la cláusula PROGRAM

TYPE para procedimientos C, el valor MAIN de la cláusula PROGRAM TYPE

recibe soporte en sentencias CREATE PROCEDURE, donde el valor de la cláusula

LANGUAGE es C.

El valor MAIN de la cláusula PROGRAM TYPE es necesario para rutinas con más

de noventa parámetros.

Cuando se especifica la cláusula PROGRAM TYPE MAIN, los procedimientos

deben implementarse utilizando una signatura que sea coherente con el estilo por

omisión correspondiente a una rutina principal en una archivo de código de fuente

C. Esto no significa que la rutina tenga que implementarse utilizando una función

denominada main, sino que los parámetros tienen que pasarse en el formato que se

asocia generalmente a una implementación de aplicación de la rutina main con

tipo por omisión que utilice los argumentos de programación argc y argv típicos

de C.

A continuación figura un ejemplo de una signatura de rutinas C o C++ que cumple

la especificación PGRAM TYPE MAIN:

SQL_API_RC SQL_API_FN functionName(int argc, char **argv)

{

...

}

El número total de argumentos de la función se especifica mediante el valor de

argc. Los valores de los argumentos se pasan como elementos de matriz dentro de


la matriz argv. El número y el orden de los argumentos depende del valor de la

cláusula PARAMETER STYLE especificada en la sentencia CREATE PROCEDURE.

Por ejemplo, supongamos que tenemos la siguiente sentencia CREATE

PROCEDURE para un procedimiento C que deba tener un estilo PROGRAM TYPE

MAIN y el PARAMETER STYLE SQL recomendado:

CREATE PROCEDURE MAIN_EXAMPLE (IN job CHAR(8),

OUT salary DOUBLE)

SPECIFIC CPP_MAIN_EXAMPLE


NOT DETERMINISTIC

LANGUAGE C

PARAMETER STYLE SQL

NO DBINFO

FENCED NOT THREADSAFE

READS SQL DATA

PROGRAM TYPE MAIN

EXTERNAL NAME ’spserver!MainExample’@

La implementación de signatura de rutina correspondiente a esta sentencia

CREATE PROCEDURE es la siguiente:

//*****************************************************

// Procedimiento almacenado: MainExample

//

// Parámetros SQL:

// IN: argv[1] - job (char[8])

// OUT: argv[2] - salary (double)

//*****************************************************

SQL_API_RC SQL_API_FN MainExample(int argc, char **argv)

{

...

}

Puesto que se utiliza PARAMETER STYLE SQL, además de los valores de los

parámetros SQL que se pasan en el momento de la invocación del procedimiento,

también se pasan a la rutina los parámetros adicionales necesarios para este estilo.

Se puede acceder a los valores de parámetros haciendo referencia al elemento de la

matriz argv que interesa dentro del código fuente. Para el ejemplo anterior, los

elementos de matriz argc y argv contienen los siguientes valores:

argc : Número de elementos de la matriz argv

argv[0]: Nombre de la función

argv[1]: Valor de parámetro job (char[8], input)

argv[2]: Valor de parámetro salary (double, output)

argv[3]: indicador nulo para parámetro job

argv[4]: indicador nulo para parámetro salary

argv[5]: sqlstate (char[6], output)

argv[6]: qualName (char[28], output)

argv[7]: specName (char[19], output)

argv[8]: diagMsg (char[71], output)

Tipos de datos de SQL soportados en rutinas C y C++

La tabla siguiente lista las correlaciones soportadas entre los tipos de datos de SQL

y los tipos de datos de C para las rutinas. Junto a cada tipo de datos de C/C++, se

encuentra el tipo definido correspondiente de sqludf.h.


Tabla 28. Tipos de datos de SQL correlacionados con declaraciones C/C++

Tipo de columna de SQL Tipo de datos de C/C++ Descripción del tipo de columna de SQL

SMALLINT sqlint16

SQLUDF_SMALLINT


INTEGER sqlint32

SQLUDF_INTEGER


BIGINT sqlint64

SQLUDF_BIGINT


REAL

FLOAT(n) donde 1<=n<=24

float

SQLUDF_REAL

Coma flotante de precisión simple

DOUBLE

FLOAT

FLOAT(n) donde 25<=n<=53

double

SQLUDF_DOUBLE

Coma flotante de precisión doble

DECIMAL(p, s) No soportado. Para pasar un valor decimal, defina el parámetro

como tipo de datos convertible desde DECIMAL

(por ejemplo, CHAR o DOUBLE) y convierta

explícitamente el argumento a este tipo.

CHAR(n) char[n+1] donde n es suficientemente

grande como para que contenga los

datos

1<=n<=254

SQLUDF_CHAR

Serie de caracteres de longitud fija terminada en

nulo

CHAR(n) FOR BIT DATA char[n] donde n es suficientemente


1<=n<=254

SQLUDF_CHAR

Serie de caracteres de longitud fija no terminada en

nulo

VARCHAR(n) char[n+1] donde n es suficientemente


1<=n<=32 672

SQLUDF_VARCHAR

Serie de longitud variable terminada en nulo

VARCHAR(n) FOR BIT DATA struct {

sqluint16 length;

char[n]

}

1<=n<=32 672

SQLUDF_VARCHAR_FBD


terminada en nulo

LONG VARCHAR struct {

sqluint16 length;

char[n]

}

1<=n<=32 700

SQLUDF_LONG


terminada en nulo

CLOB(n) struct {

sqluint32 length;

char data[n];

}

1<=n<=2 147 483 647

SQLUDF_CLOB



serie de 4 bytes


Tabla 28. Tipos de datos de SQL correlacionados con declaraciones C/C++ (continuación)


BLOB(n) struct {

sqluint32 length;

char data[n];

}

1<=n<=2 147 483 647

SQLUDF_BLOB

Serie binaria de longitud variable no terminada en

nulo con indicador de longitud de serie de 4 bytes

DATE char[11]

SQLUDF_DATE

Serie de caracteres terminada en nulo con el

formato siguiente:

aaaa-mm-dd

TIME char[9]

SQLUDF_TIME


formato siguiente:

hh.mm.ss

TIMESTAMP char[27]

SQLUDF_STAMP


formato siguiente:

aaaa-mm-dd-hh.mm.ss.nnnnnn

LOB LOCATOR sqluint32

SQLUDF_LOCATOR


DATALINK struct {

sqluint32 version;

char linktype[4];

sqluint32 url_length;

sqluint32 comment_length;

char reserve2[8];

char url_plus_comment[230];

}

SQLUDF_DATALINK

GRAPHIC(n) sqldbchar[n+1] donde n es


los datos

1<=n<=127

SQLUDF_GRAPH

Serie de caracteres de doble byte y longitud fija

terminada en nulo

VARGRAPHIC(n) sqldbchar[n+1] donde n es


los datos

1<=n<=16 336

SQLUDF_GRAPH



LONG VARGRAPHIC struct {

sqluint16 length;

sqldbchar[n]

}

1<=n<=16 350

SQLUDF_LONGVARG



DBCLOB(n) struct {

sqluint32 length;

sqldbchar data[n];

}

1<=n<=1 073 741 823

SQLUDF_DBCLOB



serie de 4 bytes


Tabla 28. Tipos de datos de SQL correlacionados con declaraciones C/C++ (continuación)


XML AS CLOB struct {

sqluint32 length;

char data[n];

}

1<=n<=2 147 483 647

SQLUDF_CLOB

Serie de caracteres serializados de longitud variable

no terminada en nulo con indicador de longitud de

serie de 4 bytes.

Nota: Los tipos de datos XML solo se pueden implementar como tipos de datos

CLOB en rutinas externas implementadas en C o C++.

Nota: Los tipos de datos siguientes sólo están disponibles en los entornos DBCS o

EUC si se compilan previamente con la opción WCHARTYPE

NOCONVERT:

v GRAPHIC(n)

v VARGRAPHIC(n)

v LONG VARGRAPHIC

v DBCLOB(n)








Manejo de tipos de datos de SQL en rutinas C y C++

En este apartado se identifican los tipos válidos para parámetros y resultados de

rutinas y se especifica cómo se debe definir el argumento correspondiente en la

rutina, en los lenguajes C o C++. Todos los argumentos de la rutina se deben pasar

como punteros al tipo de datos adecuado. Observe que, si utiliza el archivo de

inclusión sqludf.h y los tipos definidos en éste, puede generar automáticamente

estructuras y variables del lenguaje que sean correctas para los distintos tipos de

datos y compiladores. Por ejemplo, para BIGINT puede utilizar el tipo de datos

SQLUDF_BIGINT a fin de ocultar las diferencias en el tipo requerido para la

representación de BIGINT entre distintos compiladores.

El que gobierna el formato de los valores de argumento es el tipo de datos para

cada parámetro definido en la sentencia CREATE de la rutina. A fin de obtener el

valor en el formato adecuado, puede ser necesario realizar promociones a partir

del tipo de datos del argumento. DB2 lleva a cabo automáticamente estas

promociones sobre los valores de los argumentos. No obstante, si se especifican

tipos de datos incorrectos en el código de la rutina, se producirá un

comportamiento imprevisible, como, por ejemplo, pérdida de datos o

terminaciones anómalas.

Para el resultado de un método o de una función escalar, es el tipo de datos

especificado en la cláusula CAST FROM de la sentencia CREATE FUNCTION el


que define el formato. Si no hay ninguna cláusula CAST FROM presente, define el

formato el tipo de datos especificado en la cláusula RETURNS.

En el ejemplo siguiente, la presencia de la cláusula CAST FROM significa que el

cuerpo de la rutina devuelve un SMALLINT y que DB2 convierte el valor a

INTEGER antes de pasarlo a la sentencia en que se produce la referencia a la

función:

... RETURNS INTEGER CAST FROM SMALLINT ...

En este caso, la rutina se debe escribir de forma que genere un SMALLINT, tal

como se define más adelante en este apartado. Tenga en cuenta que el tipo de

datos CAST FROM se debe poder convertir al tipo de datos de RETURNS, por lo

que no es posible elegir arbitrariamente otro tipo de datos.

A continuación se muestra una lista de los tipos de SQL y sus representaciones en

los lenguajes C/C++. Esta lista incluye información sobre si cada tipo es válido

como parámetro o como resultado. También se incluyen ejemplos de cómo pueden

aparecer los tipos como definición de argumentos en la rutina, en los lenguajes C o

C++:

v SMALLINT

Válidos. Se representan en C como SQLUDF_SMALLINT o sqlint16.

Ejemplo:

sqlint16 *arg1; /* ejemplo de SMALLINT */

Cuando defina parámetros enteros de una rutina, considere la posibilidad de

utilizar INTEGER en lugar de SMALLINT, ya que DB2 no promociona los

argumentos INTEGER a SMALLINT. Por ejemplo, suponga que define una UDF

del modo siguiente:

CREATE FUNCTION SIMPLE(SMALLINT)...

Si invoca la función SIMPLE utilizando datos INTEGER (... SIMPLE(1)...),

recibirá un error SQLCODE -440 (SQLSTATE 42884) indicando que no se ha

encontrado la función, y es posible que los usuarios finales de esta función no

perciban la razón del mensaje. En el ejemplo anterior, 1 es un INTEGER, por lo

que puede convertirlo a SMALLINT o puede definir el parámetro como

INTEGER.

v INTEGER o INT

Válidos. Se representan en C como SQLUDF_INTEGER o sqlint32. Debe ejecutar

#include sqludf.h o #include sqlsystm.h para tomar esta definición.

Ejemplo:

sqlint32 *arg2; /* ejemplo de INTEGER */

v BIGINT

Válidos. Se representan en C como SQLUDF_BIGINT o sqlint64.

Ejemplo:

sqlint64 *arg3; /* ejemplo de INTEGER */

DB2 define el tipo sqlint64 del lenguaje C para superar las diferencias entre

definiciones del entero con signo de 64 bits en compiladores y sistemas

operativos. Debe ejecutar #include sqludf.h o #include sqlsystm.h para tomar

la definición.

v REAL o FLOAT(n) donde 1 <= n <= 24

Válidos. Se representan en C como SQLUDF_REAL o float.

Ejemplo:


float *result; /* ejemplo de REAL */

v DOUBLE o DOUBLE PRECISION o FLOAT o FLOAT(n) donde 25 <= n <= 53

Válidos. Se representan en C como SQLUDF_DOUBLE o double.

Ejemplo:

double *result; /* ejemplo de DOUBLE */

v DECIMAL(p,s) o NUMERIC(p,s)

No válidos, puesto que no existe ninguna representación en lenguaje C. Si desea

pasar un valor decimal, debe definir el parámetro como de tipo de datos

DECIMAL que se puede convertir (por ejemplo, CHAR o DOUBLE) y convertir

explícitamente el argumento a este tipo. En el caso de DOUBLE, no es necesario

que convierta explícitamente un argumento decimal a un parámetro DOUBLE,

ya que DB2 lo promociona automáticamente.

Ejemplo:

Suponga que tiene dos columnas, WAGE como DECIMAL(5,2) y HOURS como

DECIMAL(4,1), y que desea escribir una UDF para calcular el pago semanal en

base al salario, el número de horas trabajadas y algunos otros factores. La UDF

podría ser como la siguiente:

CREATE FUNCTION WEEKLY_PAY (DOUBLE, DOUBLE, ...)

RETURNS DECIMAL(7,2) CAST FROM DOUBLE

...;

Para la UDF anterior, los dos primeros parámetros corresponden al salario y al

número de horas. Invoque a la UDF WEEKLY_PAY en la sentencia de selección

de SQL, del modo siguiente:

SELECT WEEKLY_PAY (WAGE, HOURS, ...) ...;

Observe que no se requiere ninguna conversión explícita porque los argumentos

DECIMAL se pueden convertir a DOUBLE.

Alternativamente, puede definir WEEKLY_PAY con argumentos CHAR, del

modo siguiente:

CREATE FUNCTION WEEKLY_PAY (VARCHAR(6), VARCHAR(5), ...)

RETURNS DECIMAL (7,2) CAST FROM VARCHAR(10)

...;

La puede invocar así:

SELECT WEEKLY_PAY (CHAR(WAGE), CHAR(HOURS), ...) ...;

Observe que se requiere una conversión explícita porque los argumentos

DECIMAL no se pueden promocionar a VARCHAR.

Una ventaja de utilizar parámetros de coma flotante es que resulta fácil realizar

operaciones aritméticas sobre los valores de la rutina; una ventaja de utilizar

parámetros de tipo carácter es que siempre es posible representar exactamente el

valor decimal. Esto no es siempre posible con la coma flotante.

v CHAR(n) o CHARACTER(n) con o sin el modificador FOR BIT DATA.

Válidos. Se representan en C como SQLUDF_CHAR o char...[n+1] (ésta es una

serie C terminada en nulo).

Ejemplo:

char arg1[14]; /* ejemplo de CHAR(13) */

char *arg1; /* también se puede aceptar */

Los parámetros de la rutina de entrada del tipo de datos CHAR siempre

terminan automáticamente en nulo. Para un parámetro de entrada CHAR(n),

donde n es la longitud del tipo de datos CHAR, n bytes de datos se mueven al

almacenamiento intermedio en la implementación de la rutina y el carácter

situado en la posición n + 1 se establece en el carácter de terminador nulo ASCII

(X'00').


La rutina debe terminar en nulo de forma explícita los parámetros de salida de

los procedimientos y los valores de retorno de las funciones del tipo de datos

CHAR. para un valor de retorno de una UDF especificada por la cláusula

RETURNS, como por ejemplo RETURNS CHAR(n), o un parámetro de salida de

un procedimiento especificado como CHAR(n), donde n es la longitud del valor

CHAR, debe existir un terminador nulo dentro de los primeros n+1 bytes del

almacenamiento intermedio. Si se encuentra un terminador nulo dentro de los

primeros n+1 bytes del almacenamiento intermedio, los restantes bytes, hasta el

byte n, se establecen en los caracteres en blanco de ASCII (X'20'). Si no se

encuentra ningún terminador nulo, se produce un error de SQL (SQLSTATE

39501).

Para los parámetros de entrada y salida de los valores de retorno de

procedimientos o funciones del tipo de datos CHAR que también especifican la

cláusula FOR BIT DATA, que indica que los datos se deben manipular en su

formato binario, no se utilizan terminadores nulos para indicar el final del valor

del parámetro. Para el valor de retorno de la función RETURNS CHAR(n) FOR

BIT DATA o para un parámetro de salida de CHAR(n) FOR BIT DATA, los n

primeros bytes del almacenamiento intermedio se copian independientemente de

las ocurrencias de los terminados nulos de serie dentro de los n primeros bytes.

Los caracteres de terminador nulo identificados dentro del almacenamiento

intermedio se pasan por alto como terminados nulos y simplemente se tratan

como datos normales.

Tenga precaución al utilizar las funciones normales de manejo de series C en

una rutina que manipule un valor FOR BIT DATA, ya que muchas de estas

funciones buscan un terminador nulo para delimitar un argumento de serie y los

terminadores nulos (X'00') pueden aparecer legítimamente en medio de un valor

FOR BIT DATA. El uso de las funciones C en los valores FOR BIT DATA puede

causar el truncamiento no deseado del valor de datos.

Cuando defina parámetros de tipo carácter de una rutina, piense en la

posibilidad de utilizar VARCHAR en lugar de CHAR, puesto que DB2 no

promociona los argumentos VARCHAR a CHAR y los literales de serie se

consideran automáticamente VARCHAR. Por ejemplo, suponga que define una

UDF del modo siguiente:

CREATE FUNCTION SIMPLE(INT,CHAR(1))...

Si invoca la función SIMPLE utilizando datos VARCHAR

(... SIMPLE(1,’A’)...), recibirá un error SQLCODE -440 (SQLSTATE 42884)

indicando que no se ha encontrado la función, y es posible que los usuarios

finales de esta función no perciban la razón del mensaje. En el ejemplo anterior,

’A’ es VARCHAR, por lo que puede convertirlo a CHAR o puede definir el

parámetro como VARCHAR.

v VARCHAR(n) FOR BIT DATA o LONG VARCHAR con o sin el modificador

FOR BIT DATA.

Válidos. Representan VARCHAR(n) FOR BIT DATA en C como

SQLUDF_VARCHAR_FBD. Representan LONG VARCHAR en C como SQLUDF_LONG. De

lo contrario, representan estos dos tipos de SQL en C como una estructura

similar a la siguiente del archivo de inclusión sqludf.h:

struct sqludf_vc_fbd

{

unsigned short length; /* longitud de los datos */

char data[1]; /* primer carácter de datos */

};

El [1] indica una matriz para el compilador. No significa que sólo se pase un

carácter; dado que se pasa la dirección de la estructura, y no la estructura real,

proporciona una manera de utilizar la lógica de matrices.


Estos valores no se representan como series C terminadas en nulo porque el

carácter de nulo podría ser admisible formando parte del valor de los datos. Se

pasa explícitamente a la rutina la longitud de los parámetros utilizando la

variable de estructura length. Para la cláusula RETURNS, la longitud que se

pasa a la rutina es la longitud del almacenamiento intermedio. Lo que el cuerpo

de la rutina debe devolver, utilizando la variable de estructura length, es la

longitud real del valor de los datos.

Ejemplo:

struct sqludf_vc_fbd *arg1; /* ejemplo de VARCHAR(n) FOR BIT DATA */

struct sqludf_vc_fbd *result; /* y también de LONG VARCHAR FOR BIT DATA */

v VARCHAR(n) sin FOR BIT DATA.

Válidos. Se representan en C como SQLUDF_VARCHAR o char...[n+1]. (Ésta es una

serie C terminada en nulo.)

Para un parámetro VARCHAR(n), DB2 colocará un nulo en la posición (k+1),

donde k es la longitud de la serie en particular. Las funciones de manejo de

series C son adecuadas para la manipulación de estos valores. Para un valor de

RETURNS VARCHAR(n) o un parámetro de salida de un procedimiento

almacenado, el cuerpo de la rutina debe delimitar el valor real con un nulo

porque DB2 determinará la longitud del resultado a partir de este carácter de

nulo.

Ejemplo:

char arg2[51]; /* ejemplo de VARCHAR(50) */

char *result; /* también se puede aceptar */

v DATE

Válidos. Se representan en C como SQLUDF_DATE o CHAR(10), es decir, como

char...[11]. El valor de fecha siempre se pasa a la rutina con formato ISO:

aaaa-mm-dd

Ejemplo:

char arg1[11]; /* ejemplo de DATE */


Nota: Para los valores de retorno de DATE, TIME y TIMESTAMP, DB2 exige que

los caracteres estén en el formato definido y, si no es así, DB2 puede

malinterpretar el valor (por ejemplo, 2001-04-03 se interpretaría como el 3

de abril, aunque la intención es que interprete el 4 de marzo) o generaría

un error (SQLCODE -493, SQLSTATE 22007).

v TIME

Válidos. Se representan en C como SQLUDF_TIME o CHAR(8), es decir, como

char...[9]. El valor de hora siempre se pasa a la rutina con formato ISO:

hh.mm.ss

Ejemplo:

char *arg; /* ejemplo para TIME */

char result[9]; /* también se puede aceptar */

v TIMESTAMP

Válidos. Se representan en C como SQLUDF_STAMP o CHAR(26), es decir, como

char...[27]. El valor de indicación de la hora siempre se pasa con el formato

siguiente:

aaaa-mm-dd-hh.mm.ss.nnnnnn

Ejemplo:

char arg1[27]; /* ejemplo de TIMESTAMP */


v GRAPHIC(n)


Válidos. Se representan en C como SQLUDF_GRAPH o sqldbchar[n+1]. (Ésta es una

serie gráfica terminada en nulo.) Tenga en cuenta que puede utilizar

wchar_t[n+1] en los sistemas operativos en los que wchar_t está definido con 2

bytes de longitud; no obstante, es recomendable sqldbchar.

Para un parámetro GRAPHIC(n), DB2 mueve n caracteres de doble byte al

almacenamiento intermedio y establece los dos bytes siguientes en nulo. Los

datos que se pasan de DB2 a una rutina están en formato DBCS y es de esperar

que el resultado devuelto esté en formato DBCS. Este comportamiento es el

mismo que si se utiliza la opción de precompilador WCHARTYPE

NOCONVERT. Para un valor de RETURNS GRAPHIC(n) o un parámetro de

salida de un procedimiento almacenado, DB2 busca un CHAR GRAPHIC nulo

incorporado y, si lo encuentra, rellena el valor hasta n con caracteres GRAPHIC

en blanco.

Cuando defina parámetros gráficos de una rutina, considere la posibilidad de

utilizar VARGRAPHIC en lugar de GRAPHIC, ya que DB2 no promociona los

argumentos VARGRAPHIC a GRAPHIC. Por ejemplo, suponga que define una

rutina del modo siguiente:

CREATE FUNCTION SIMPLE(GRAPHIC)...

Si invoca la función SIMPLE utilizando datos VARGRAPHIC

(... SIMPLE('literal_gráfico')...), recibirá un error SQLCODE -440

(SQLSTATE 42884) indicando que no se ha encontrado la función, y es posible

que los usuarios finales de esta función no comprendan la razón de este

mensaje. En el ejemplo anterior, literal_gráfico es una serie DBCS literal que

se interpreta como datos VARGRAPHIC, por lo que puede convertirla a

GRAPHIC o puede definir el parámetro como VARGRAPHIC.

Ejemplo:

sqldbchar arg1[14]; /* ejemplo de GRAPHIC(13) */

sqldbchar *arg1; /* también se puede aceptar */

v VARGRAPHIC(n)

Válidos. Se representan en C como SQLUDF_GRAPH o sqldbchar[n+1]. (Ésta es una

serie gráfica terminada en nulo.) Tenga en cuenta que puede utilizar

wchar_t[n+1] en los sistemas operativos en los que wchar_t está definido con 2

bytes de longitud; no obstante, es recomendable sqldbchar.

Para un parámetro VARGRAPHIC(n), DB2 colocará un nulo gráfico en la

posición (k+1), donde k es la longitud de la aparición en particular. Un nulo

gráfico hace referencia a una situación en que todos los bytes del último carácter

de la serie gráfica contienen ceros binarios ('\0's). Los datos que se pasan de

DB2 a una rutina están en formato DBCS y es de esperar que el resultado

devuelto esté en formato DBCS. Este comportamiento es el mismo que si se

utiliza la opción de precompilador WCHARTYPE NOCONVERT. Para un valor

de RETURNS VARGRAPHIC(n) o un parámetro de salida de un procedimiento

almacenado, el cuerpo de la rutina debe delimitar el valor real con un nulo

gráfico, porque DB2 determinará la longitud del resultado a partir de este

carácter de nulo gráfico.

Ejemplo:

sqldbchar args[51], /* ejemplo de VARGRAPHIC(50) */

sqldbchar *result, /* también se puede aceptar */

v LONG VARGRAPHIC

Válidos. Se representan en C como SQLUDF_LONGVARG o como una estructura:

struct sqludf_vg

{

unsigned short length; /* longitud de los datos */

sqldbchar data[1]; /* primer carácter de datos */

};


Tenga en cuenta que, en la estructura anterior, puede utilizar wchar_t en lugar

de sqldbchar en los sistemas operativos en los que wchar_t está definido con 2

bytes de longitud; no obstante, es recomendable el uso de sqldbchar.

El [1] simplemente indica una matriz para el compilador. No significa que sólo

se pase un carácter gráfico. Dado que se pasa la dirección de la estructura, y no

la estructura real, se proporciona una manera de utilizar la lógica de matrices.

No se representan como series gráficas terminadas en nulo. Se pasa

explícitamente a la rutina la longitud de los parámetros, en caracteres de doble

byte, utilizando la variable de estructura length. Los datos que se pasan de DB2

a una rutina están en formato DBCS y es de esperar que el resultado devuelto

esté en formato DBCS. Este comportamiento es el mismo que si se utiliza la

opción de precompilador WCHARTYPE NOCONVERT. Para la cláusula

RETURNS o un parámetro de salida de un procedimiento almacenado, la

longitud que se pasa a la rutina es la longitud del almacenamiento intermedio.

Lo que el cuerpo de la rutina debe devolver, utilizando la variable de estructura

length, es la longitud real del valor de los datos, en caracteres de doble byte.

Ejemplo:

struct sqludf_vg *arg1; /* ejemplo de VARGRAPHIC(n) */

struct sqludf_vg *result; /* y también de LONG VARGRAPHIC */

v BLOB(n) y CLOB(n)

Válidos. Se representan en C como SQLUDF_BLOB, como SQLUDF_CLOB o como una

estructura:

struct sqludf_lob

{

sqluint32 length; /* longitud en bytes */

char data[1]; /* primer byte del lob */

};


se pase un carácter; dado que se pasa la dirección de la estructura, y no la

estructura real, proporciona una manera de utilizar la lógica de matrices.

No se representan como series C terminadas en nulo. Se pasa explícitamente a la

rutina la longitud de los parámetros utilizando la variable de estructura length.

Para la cláusula RETURNS o un parámetro de salida de un procedimiento

almacenado, la longitud que se devuelve a la rutina es la longitud del

almacenamiento intermedio. Lo que el cuerpo de la rutina debe devolver,

utilizando la variable de estructura length, es la longitud real del valor de los

datos.

Ejemplo:

struct sqludf_lob *arg1; /* ejemplo de BLOB(n), CLOB(n) */

struct sqludf_lob *result;

v DBCLOB(n)

Válidos. Se representan en C como SQLUDF_DBCLOB o como una estructura:

struct sqludf_lob

{

sqluint32 length; /* longitud en caracteres gráficos */

sqldbchar data[1]; /* primer byte del lob */

};

Tenga en cuenta que, en la estructura anterior, puede utilizar wchar_t en lugar

de sqldbchar en los sistemas operativos en los que wchar_t está definido con 2

bytes de longitud; no obstante, es recomendable el uso de sqldbchar.


se pase un carácter gráfico; dado que se pasa la dirección de la estructura, y no

la estructura real, proporciona una manera de utilizar la lógica de matrices.


No se representan como series gráficas terminadas en nulo. Se pasa

explícitamente a la rutina la longitud de los parámetros utilizando la variable de

estructura length. Los datos que se pasan de DB2 a una rutina están en formato

DBCS y es de esperar que el resultado devuelto esté en formato DBCS. Este

comportamiento es el mismo que si se utiliza la opción de precompilador

WCHARTYPE NOCONVERT. Para la cláusula RETURNS o un parámetro de

salida de un procedimiento almacenado, la longitud que se pasa a la rutina es la

longitud del almacenamiento intermedio. Lo que el cuerpo de la rutina debe

devolver, utilizando la variable de estructura length, es la longitud real del valor

de los datos, con todas estas longitudes expresadas en caracteres de doble byte.

Ejemplo:

struct sqludf_lob *arg1; /* ejemplo de DBCLOB(n) */


v Tipos diferenciados

Válidos o no válidos en función del tipo base. Los tipos diferenciados se

pasarán a la UDF con el formato del tipo base del UDT, por lo que se pueden

especificar si y sólo si es válido el tipo base.

Ejemplo:

struct sqludf_lob *arg1; /* para tipos diferenciados basados en BLOB(n) */

double *arg2; /* para tipos diferenciados basados en DOUBLE */

char res[5];/* para tipos diferenciados basados en CHAR(4) */

v XML

Válidos. Se representa en C como SQLUDF_XML o como se representa el tipo de

datos CLOB; es decir, con una estructura:

struct sqludf_lob

{

sqluint32 length; /* longitud en bytes */

char data[1]; /* primer byte del lob */

};


se pase un carácter; dado que se pasa la dirección de la estructura, y no la

estructura real, proporciona una manera de utilizar la lógica de matrices.

No se representan como series C terminadas en nulo. Se pasa explícitamente a la

rutina la longitud de los parámetros utilizando la variable de estructura length.

Para la cláusula RETURNS o un parámetro de salida de un procedimiento

almacenado, la longitud que se devuelve a la rutina es la longitud del

almacenamiento intermedio. Lo que el cuerpo de la rutina debe devolver,

utilizando la variable de estructura length, es la longitud real del valor de los

datos.

Ejemplo:

struct sqludf_lob *arg1; /* ejemplo de XML(n) */


La asignación de valores de parámetros y variables XML y el acceso a ellos en

código externo de la rutina C y C++ se hace como para los valores CLOB.

v Tipos diferenciados AS LOCATOR, o cualquier tipo de LOB AS LOCATOR

Válidos para los parámetros y resultados de UDF y métodos. Sólo se puede

utilizar para modificar tipos de LOB o cualquier tipo diferenciado que esté

basado en un tipo de LOB. Su representación en C es como SQLUDF_LOCATOR o

como entero de cuatro bytes.

El valor de localizador se puede asignar a cualquier variable del lenguaje

principal de localizador que sea de un tipo compatible, y luego se puede utilizar

en una sentencia de SQL. Esto significa que las variables de localizador

únicamente son de utilidad en las UDF y los métodos definidos con un


indicador de acceso a SQL que sea CONTAINS SQL o superior. Para que sean

compatibles con las UDF y los métodos existentes, las API de localizador se

siguen soportando para las UDF NOT FENCED NO SQL. No se recomienda el

uso de estas API para las funciones nuevas.

Ejemplo:

sqludf_locator *arg1; /* argumento de localizador */

sqludf_locator *result; /* resultado del localizador */


SQL TYPE IS CLOB LOCATOR arg_loc;

SQL TYPE IS CLOB LOCATOR res_loc;


/* Extraer algunos caracteres del medio */

/* del argumento y devolverlos */

*arg_loc = arg1;

EXEC SQL VALUES SUBSTR(arg_loc, 10, 20) INTO :res_loc;

*result = res_loc;

v Tipos estructurados

Válidos para los parámetros y resultados de UDF y métodos en que exista una

función de transformación apropiada. Los parámetros de tipos estructurados se

pasarán a la función o al método en el tipo de resultado de la función de

transformación FROM SQL. Los resultados de tipos estructurados se pasarán en

el tipo de parámetro de la función de transformación TO SQL.

v DATALINK

Válidos. Se representan en C como SQLUDF_DATALINK o como una estructura

similar a la siguiente del archivo de inclusión sqludf.h:

struct sqludf_datalink {

sqluint32 version;

char linktype[4];

sqluint32 url_length;

sqluint32 comment_length;

char reserve2[8];

char url_plus_comment[230];

}





v “Funciones de transformación y grupos de transformación” en Desarrollo de SQL

y rutinas externas







Paso de argumentos a rutinas C, C++, OLE o COBOL

Además de los argumentos de SQL que se especifican en la referencia DML para

una rutina, DB2 pasa argumentos adicionales al cuerpo de la rutina externa. La

naturaleza y el orden de estos argumentos lo determina el estilo de parámetros con

que se ha registrado la rutina. Para asegurarse de que se intercambie correctamente


la información entre los invocadores y el cuerpo de la rutina, se tiene que cerciorar

de que la rutina acepte los argumentos en el orden en que se le pasen, según el

estilo de parámetros que se utilice. El archivo de inclusión sqludf le puede servir

para el manejo y uso de estos argumentos.

Los estilos de parámetros siguientes sólo son aplicables a las rutinas LANGUAGE

C, LANGUAGE OLE y LANGUAGE COBOL.

Rutinas PARAMETER STYLE SQL

��

�

�

argumento-SQL

ind-argumento-SQL

sqlstate nombre-rutina �

� nombre-específico mensaje-diagnóstico

área-reutilizable �

� tipo-llamada

dbinfo ��

Procedimientos PARAMETER STYLE DB2SQL

��

�

argumento-SQL

matriz-ind-argumento-SQL

sqlstate nombre-rutina �

� nombre-específico mensaje-diagnóstico

dbinfo ��

Procedimientos PARAMETER STYLE GENERAL

��

�

argumento-SQL

dbinfo ��

Procedimientos PARAMETER STYLE GENERAL WITH NULLS

��

�

argumento-SQL


dbinfo ��

Nota: Para las UDF y los métodos, PARAMETER STYLE SQL es equivalente a

PARAMETER STYLE DB2SQL.

Los argumentos para los estilos de parámetros anteriores se describen del modo

siguiente:

argumento-SQL...

Cada argumento-SQL representa un valor de entrada o salida definido al

crear la rutina. La lista de argumentos se determina del modo siguiente:


v Para una función escalar, un argumento para cada parámetro de entrada

para la función, seguidos de un argumento-SQL para el resultado de la

función.

v Para una función de tabla, un argumento para cada parámetro de

entrada para la función, seguidos de un argumento-SQL para cada

columna de la tabla de resultados de la función.

v Para un método, un argumento-SQL para el tipo sujeto del método, luego

un argumento para cada parámetro de entrada para el método, seguidos

de un argumento-SQL para el resultado del método.

v Para un procedimiento almacenado, un argumento-SQL para cada

parámetro del procedimiento almacenado.

Cada uno de los argumentos-SQL se utiliza del modo siguiente:

v Parámetro de entrada de una función o método, tipo sujeto de un

método o parámetro IN de un procedimiento almacenado

DB2 establece este argumento antes de llamar a la rutina. El valor de

cada uno de estos argumentos se toma de la expresión especificada en la

invocación de la rutina. Se expresa en el tipo de datos de la definición

del parámetro correspondiente en la sentencia CREATE.

v Resultado de una función o método, o parámetro OUT de un

procedimiento almacenado

La rutina establece este argumento antes de volver a DB2. DB2 asigna el

almacenamiento intermedio y pasa la dirección del mismo a la rutina. La

rutina coloca el valor del resultado en el almacenamiento intermedio.

DB2 asigna un espacio de almacenamiento intermedio suficiente para

que contenga el valor expresado en el tipo de datos. En los tipos de

caracteres y LOB, esto significa que se asigna el tamaño máximo

definido en la sentencia de creación.

Para los métodos y funciones escalares, el tipo de datos del resultado se

define en la cláusula CAST FROM, si está presente, o en la cláusula

RETURNS, si no hay ninguna cláusula CAST FROM presente.

Para las funciones de tabla, DB2 define una optimización del

rendimiento si no se tienen que devolver a DB2 todas las columnas

definidas. Si escribe una UDF que se aproveche de esta característica,

ésta sólo devolverá las columnas que necesite la sentencia que hace

referencia a la función de tabla. Por ejemplo, piense en una sentencia

CREATE FUNCTION para una función de tabla definida con 100

columnas de resultado. Si una sentencia determinada que hace referencia

a la función sólo está interesada en dos de ellas, esta optimización

permite que la UDF sólo devuelva estas dos columnas de cada fila, y no

invierta tiempo en las otras 98 columnas. Para obtener más información

sobre la optimización mencionada, consulte el argumento dbinfo más

adelante.

Por cada valor devuelto, la rutina no debe devolver más bytes de los

necesarios para el tipo de datos y la longitud del resultado. Los valores

máximos se definen durante la creación de la entrada de catálogo de la

rutina. Una sobregrabación por parte de la rutina puede ocasionar

resultados imprevisibles o una terminación anómala.

v Parámetro INOUT de un procedimiento almacenado

Este argumento se comporta como los parámetros IN y OUT y, por

consiguiente, sigue los dos conjuntos de reglas indicados anteriormente.

DB2 establecerá el argumento antes de llamar al procedimiento

almacenado. El almacenamiento intermedio asignado por DB2 para el


argumento es lo suficientemente grande como para contener el tamaño

máximo del tipo de datos del parámetro definido en la sentencia

CREATE PROCEDURE. Por ejemplo, un parámetro INOUT de tipo

CHAR puede tener un varchar de 10 bytes que entre en el

procedimiento almacenado y un varchar de 100 bytes que salga del

procedimiento almacenado. El procedimiento almacenado establece el

almacenamiento intermedio antes de volver a DB2.

DB2 alinea los datos para argumento-SQL en función del tipo de datos y del

sistema operativo del servidor, también conocido como plataforma.

ind-argumento-SQL...

Hay un ind-argumento-SQL para cada argumento-SQL que se pase a la

rutina. El ind-argumento-SQL número n corresponde al argumento-SQL

número n e indica si el argumento-SQL tiene un valor o es nulo (NULL).

Cada uno de los ind-argumento-SQL se utiliza del modo siguiente:

v Parámetro de entrada de una función o método, tipo sujeto de un

método o parámetro IN de un procedimiento almacenado

DB2 establece este argumento antes de llamar a la rutina. Contiene uno

de los valores siguientes:

0 El argumento está presente y no es NULL.

-1 El argumento está presente y su valor es NULL.Si la rutina se ha definido con RETURNS NULL ON NULL INPUT, el

cuerpo de la rutina no tiene necesidad de comprobar un valor NULL.

Sin embargo, si se ha definido con CALLED ON NULL INPUT,

cualquier argumento puede ser NULL y la rutina debe comprobar el

ind-argumento-SQL antes de utilizar el argumento-SQL correspondiente.

v Resultado de una función o método, o parámetro OUT de un

procedimiento almacenado

La rutina establece este argumento antes de volver a DB2. La rutina

utiliza este argumento para señalar si el valor del resultado en concreto

es NULL:

0 El resultado no es NULL.

-1 El resultado es el valor NULL.Aunque la rutina se haya definido con RETURNS NULL ON NULL

INPUT, el cuerpo de la rutina tiene que establecer el ind-argumento-SQL

del resultado. Por ejemplo, una función de división puede establecer el

resultado en nulo cuando el denominador sea cero.

Para los métodos y funciones escalares, DB2 trata un resultado NULL

como un error aritmético si se dan las circunstancias siguientes:

– El parámetro de configuración de base de datos dft_sqlmathwarn es

YES

– Uno de los argumentos de entrada es nulo debido a un error

aritmético

También sucede así si se define la función con la opción RETURNS

NULL ON NULL INPUT

Para las funciones de tabla, si la UDF se aprovecha de la optimización

utilizando la lista de columnas del resultado, sólo es necesario establecer

los indicadores correspondientes a las columnas requeridas.

v Parámetro INOUT de un procedimiento almacenado

Este argumento se comporta como los parámetros IN y OUT y, por




almacenado. El procedimiento almacenado establece el

ind-argumento-SQL antes de volver a DB2.

Cada ind-argumento-SQL toma la forma de un valor SMALLINT. DB2 alinea

los datos para ind-argumento-SQL en función del tipo de datos y del

sistema operativo del servidor.


En la matriz-ind-argumento-SQL, existe un elemento para cada

argumento-SQL pasado al procedimiento almacenado. El elemento número

n de la matriz-ind-argumento-SQL corresponde al argumento-SQL número n

e indica si el argumento-SQL tiene un valor o es NULL.

Cada elemento de la matriz-ind-argumento-SQL se utiliza del modo

siguiente:

v Parámetro IN de un procedimiento almacenado

DB2 establece este elemento antes de llamar a la rutina. Contiene uno de

los valores siguientes:

0 El argumento está presente y no es NULL.

-1 El argumento está presente y su valor es NULL.

Si el procedimiento almacenado se ha definido con RETURNS NULL ON

NULL INPUT, el cuerpo del procedimiento almacenado no tiene

necesidad de comprobar un valor NULL. Sin embargo, si se ha definido

con CALLED ON NULL INPUT, cualquier argumento puede ser NULL

y el procedimiento almacenado debe comprobar el ind-argumento-SQL

antes de utilizar el argumento-SQL correspondiente.

v Parámetro OUT de un procedimiento almacenado

La rutina establece este elemento antes de volver a DB2. La rutina utiliza

este argumento para señalar si el valor del resultado en concreto es

NULL:

0 o positivo

El resultado no es NULL.

negativo

El resultado es el valor NULL.v Parámetro INOUT de un procedimiento almacenado

Este elemento se comporta como los parámetros IN y OUT y, por



almacenado. El procedimiento almacenado establece el elemento de

matriz-ind-argumento-SQL antes de volver a DB2.

Cada elemento de matriz-ind-argumento-SQL toma la forma de un valor

SMALLINT. DB2 alinea los datos para matriz-ind-argumento-SQL en función

del tipo de datos y del sistema operativo del servidor.

sqlstate La rutina establece este argumento antes de volver a DB2. Ésta lo puede

utilizar para señalar condiciones de aviso o error. La rutina puede

establecer este argumento en cualquier valor. El valor ’00000’ significa que

no se ha detectado ninguna condición de aviso ni de error. Los valores que

empiezan por ’01’ son condiciones de aviso. Los valores que empiezan por

cualquier cosa distinta de ’00’ y ’01’ son condiciones de error. Cuando se

llama a la rutina, el argumento contiene el valor ’00000’.

Para las condiciones de error, la rutina devuelve un SQLCODE de -443.

Para las condiciones de aviso, devuelve un SQLCODE de +462. Si el

SQLSTATE es 38001 ó 38502, el SQLCODE es -487.


El sqlstate toma la forma de un valor CHAR(5). DB2 alinea los datos para

sqlstate en función del tipo de datos y del sistema operativo del servidor.

nombre-rutina

DB2 establece este argumento antes de llamar a la rutina. Se trata del

nombre de función calificado que se pasa de DB2 a la rutina

El formato del nombre-rutina que se pasa es el siguiente:

esquema.rutina

Las distintas partes se separan mediante un punto. Éstos son dos ejemplos:

PABLO.BLOOP WILLIE.FINDSTRING

Este formato permite utilizar el mismo cuerpo de rutina para varias rutinas

externas, y sigue diferenciando entre las rutinas cuando se las invoca.

Nota: Aunque es posible incluir un punto en nombres de objeto y nombres

de esquema, no es aconsejable. Por ejemplo, si una función ROTATE

se encuentra en un esquema OBJ.OP, el nombre de rutina que se

pasa a la función es OBJ.OP.ROTATE, y no resulta obvio si el nombre

de esquema es OBJ u OBJ.OP.

El nombre-rutina adopta el formato de un valor VARCHAR(257). DB2 alinea

los datos para nombre-rutina en función del tipo de datos y del sistema

operativo del servidor.

nombre-específico

DB2 establece este argumento antes de llamar a la rutina. Se trata del

nombre específico de la rutina que se pasa de DB2 a la rutina.

Éstos son dos ejemplos:

WILLIE_FIND_FEB99 SQL9904281052440430

El usuario proporciona este primer valor en su sentencia CREATE. El

segundo valor, si el usuario no especifica ninguno, lo genera DB2 a partir

de la indicación de la hora actual.

Al igual que con el argumento nombre-rutina, la razón para pasar este valor

consiste en brindar a la rutina un medio para distinguir exactamente qué

rutina concreta lo está invocando.

El nombre-específico toma la forma de un valor VARCHAR(18). DB2 alinea

los datos para nombre-específico en función del tipo de datos y del sistema


mensaje-diagnóstico

La rutina establece este argumento antes de volver a DB2. La rutina puede

utilizar este argumento para insertar texto de mensaje en un mensaje de

DB2.

Cuando la rutina devuelve un error o un aviso, utilizando el argumento

sqlstate descrito anteriormente, puede incluir aquí información descriptiva.

DB2 incluye esta información como señal en su mensaje.

DB2 establece el primer carácter en nulo antes de llamar a la rutina. Al

volver, trata la serie como una serie C terminada en nulo. Esta serie se

incluirá en la SQLCA como señal de la condición de error. Como mínimo,

la primera parte de esta serie aparecerá en la SQLCA o en el mensaje del

CLP de DB2. No obstante, el número real de caracteres que aparecerán


depende de las longitudes de las otras señales, puesto que DB2 trunca las

señales para que se ajusten al límite impuesto por la SQLCA respecto a la

longitud total de las señales. Evite utilizar X'FF' en el texto, ya que este

carácter se utiliza para delimitar señales en la SQLCA.

La rutina no debe devolver más texto del que quepa en el almacenamiento

intermedio de VARCHAR(70) que se le pasa. Una sobregrabación por parte

de la rutina puede ocasionar resultados imprevisibles o una terminación

anómala.

DB2 supone que las señales de mensajes devueltas a DB2 por la rutina

están en la misma página de códigos que la rutina. La rutina se debe

asegurar de que es así. Si se utiliza el subconjunto ASCII invariable de 7

bits, la rutina puede devolver las señales de mensajes en cualquier página

de códigos.

El mensaje-diagnóstico toma la forma de un valor VARCHAR(70). DB2 alinea

los datos para mensaje-diagnóstico en función del tipo de datos y del sistema


área-reutilizable

DB2 establece este argumento antes de invocar la UDF o al método. Sólo

está presente para las funciones y los métodos en que se ha especificado la

palabra clave SCRATCHPAD durante el registro. Este argumento es una

estructura, exactamente igual que la estructura utilizada para pasar un

valor de cualquiera de los tipos de datos LOB, con los elementos

siguientes:

v Un INTEGER que contiene la longitud del área reutilizable. Si se cambia

la longitud del área reutilizable, se producirá un SQLCODE -450

(SQLSTATE 39501)

v El área reutilizable real inicializada completamente con ceros binarios del

modo siguiente:

– Para los métodos y las funciones escalares, se inicializa antes de la

primera llamada y DB2 no la suele examinar ni modificar después.

– Para las funciones de tabla, el área reutilizable se inicializa antes de la

primera (FIRST) llamada a la UDF si se especifica FINAL CALL en la

sentencia CREATE FUNCTION. A partir de esta llamada, el contenido

del área reutilizable está totalmente bajo el control de la función de

tabla. Si se ha especificado, o asumido por omisión, NO FINAL CALL

para una función de tabla, el área reutilizable se inicializa para cada

llamada OPEN, y el contenido de la misma está totalmente bajo el

control de la función de tabla entre llamadas OPEN. (Esto puede ser

muy importante para una función de tabla utilizada en una unión o

en una subconsulta. Si es necesario mantener el contenido del área

reutilizable a lo largo de las llamadas OPEN, se debe especificar

FINAL CALL en la sentencia CREATE FUNCTION. Si se especifica

FINAL CALL, además de las llamadas OPEN, FETCH y CLOSE

normales, la función de tabla recibirá también llamadas FIRST y

FINAL, con el objetivo de mantener el área reutilizable y liberar

recursos.)

El área reutilizable se puede correlacionar en la rutina utilizando el mismo

tipo que un CLOB o un BLOB, puesto que el argumento que se pasa tiene

la misma estructura.

Asegúrese de que el código de la rutina no realiza cambios fuera del

almacenamiento intermedio del área reutilizable. Una sobregrabación por


parte de la rutina puede causar resultados imprevisibles o una terminación

anómala y puede que DB2 experimente una anomalía no leve.

Si en una subconsulta se hace referencia a un método o una UDF escalar

que emplea un área reutilizable, es posible que DB2 decida renovar el área

reutilizable entre invocaciones de la subconsulta. Esta renovación se

produce después de realizar una llamada final, en caso de que se haya

especificado FINAL CALL para la UDF.

DB2 inicializa el área reutilizable de forma que el campo de datos esté

alineado para el almacenamiento de cualquier tipo de datos. Esto puede

hacer que la estructura entera del área reutilizable, incluido el campo de

longitud, esté alineada incorrectamente.

tipo-llamada

DB2 establece este argumento, si está presente, antes de invocar la UDF o

al método. Este argumento está presente para todas las funciones de tabla

y para los métodos y funciones escalares en que se ha especificado FINAL

CALL durante el registro.

A continuación, se indican todos los valores posibles actuales para

tipo-llamada. La UDF o el método debe contener una sentencia de

conmutación o de caso que pruebe explícitamente todos los valores

esperados, en lugar de contener lógica del tipo “if A do AA, else if B do

BB, else it must be C so do CC”. Esto es así porque puede que en el futuro

se añadan tipos de llamadas adicionales y, si no prueba explícitamente la

condición C, tendrá problemas cuando se añadan las nuevas posibilidades.

Notas:

1. Para todos los valores de tipo-llamada, puede ser conveniente que la

rutina establezca un valor de retorno de sqlstate y de mensaje-diagnóstico.

Esta información no se repetirá en las descripciones siguientes de cada

uno de los tipos-llamada. Para todas las llamadas, DB2 emprenderá la

acción indicada descrita anteriormente para estos argumentos.

2. El archivo de inclusión sqludf.h está destinado a la utilización con

rutinas. El archivo contiene definiciones simbólicas para los valores de

tipo-llamada siguientes, que se escriben como constantes.

Para los métodos y funciones escalares, tipo-llamada contiene:

SQLUDF_FIRST_CALL (-1)

Ésta es la primera (FIRST) llamada a la rutina para esta

sentencia. El área reutilizable (si la hay) se establece con

ceros binarios cuando se llama a la rutina. Se pasan los

valores de todos los argumentos y la rutina debe realizar

las acciones puntuales de inicialización que sean necesarias.

Además, una llamada FIRST a un método o una UDF

escalar es como una llamada NORMAL, en el sentido en

que se espera que desarrolle y devuelva una respuesta.

Nota: Si se especifica SCRATCHPAD pero no así FINAL

CALL, la rutina no tendrá este argumento de

tipo-llamada para identificar la llamada realmente

primera. En lugar de esto, se tendrá que basar en el

estado del área reutilizable, todo ceros.

SQLUDF_NORMAL_CALL (0)

Ésta es una llamada NORMAL. Se pasan todos los valores

de entrada de SQL y se espera que la rutina desarrolle y


devuelva el resultado. También puede que la rutina

devuelva información de sqlstate y de mensaje-diagnóstico.

SQLUDF_FINAL_CALL (1)

Ésta es una llamada FINAL; es decir, no se pasa ningún

valor de argumento-SQL ni de ind-argumento-SQL, y los

intentos de examinar estos valores pueden causar

resultados imprevisibles. Si también se pasa un área

reutilizable, ésta permanece inalterada desde la llamada

anterior. Se espera que la rutina libere recursos en este

punto.

SQLUDF_FINAL_CRA (255)

Ésta es una llamada FINAL, idéntica a la llamada FINAL

descrita antes, con una característica adicional, a saber, que

se crea para rutinas que están definidas como capaces de

emitir SQL, y se crea en un momento en que la rutina no

debe emitir SQL, a excepción de CLOSE cursor. (SQLCODE

-396, SQLSTATE 38505) Por ejemplo, cuando DB2 está en

medio de un proceso COMMIT, no puede tolerar nuevo

SQL, y cualquier llamada FINAL emitida para una rutina

en ese momento será una llamada 255 FINAL. Las rutinas

que no estén definidas para contener ningún nivel de

acceso a SQL nunca recibirán una llamada 255 FINAL,

mientras que las rutinas que utilizan SQL pueden recibir

cualquier tipo de llamada FINAL.

Liberación de recursos

De un método o una UDF escalar se espera que liberen los recursos que

han necesitado, por ejemplo memoria. Si se especifica FINAL CALL para la

rutina, esa llamada FINAL es el lugar natural en el que liberar recursos,

siempre que también se especifique SCRATCHPAD y se utilice para hacer

un seguimiento del recurso. Si no se especifica FINAL CALL, cualquier

recurso adquirido se debe liberar en la misma llamada.

Para las funciones de tabla, tipo-llamada contiene:

SQLUDF_TF_FIRST (-2)

Ésta es la primera (FIRST) llamada, que sólo se produce si

se ha especificado la palabra clave FINAL CALL para la

UDF. El área reutilizable se establece con ceros binarios antes

de esta llamada. Los valores de los argumentos se pasan a

la función de tabla. La función de tabla puede adquirir

memoria o realizar otra inicialización puntual de sólo

recursos. No se trata de una llamada OPEN, la cual sigue a

ésta. En una llamada FIRST, la función de tabla no debe

devolver ningún dato a DB2, ya que DB2 hace caso omiso

de los datos.

SQLUDF_TF_OPEN (-1)

Ésta es la llamada OPEN. El área reutilizable se inicializará

si se especifica NO FINAL CALL, pero no necesariamente

en caso contrario. En OPEN se pasan los valores de todos

los argumentos de SQL a la función de tabla. La función de

tabla no debe devolver ningún dato a DB2 en la llamada

OPEN.


SQLUDF_TF_FETCH (0)

Ésta es una llamada FETCH y DB2 espera que la función

de tabla devuelva una fila que comprenda el conjunto de

valores de retorno o una condición de fin de tabla,

indicada por el valor ’02000’ de SQLSTATE. Si se pasa el

área reutilizable a la UDF, al entrar ésta permanece

inalterada respecto a la llamada anterior.

SQLUDF_TF_CLOSE (1)

Ésta es una llamada CLOSE para la función de tabla.

Equilibra la llamada OPEN y se puede utilizar para

realizar cualquier proceso CLOSE externo (por ejemplo,

cerrar un archivo fuente) y para la liberación de recursos

(especialmente para el caso de NO FINAL CALL).

En los casos que implican una unión o una subconsulta, se

pueden repetir secuencias de llamadas

OPEN/FETCH.../CLOSE dentro de la ejecución una

sentencia, pero sólo habrá una llamada FIRST y una

llamada FINAL. Las llamadas FIRST y FINAL sólo se

producen si se especifica FINAL CALL para la función de

tabla.

SQLUDF_TF_FINAL (2)

Ésta es una llamada FINAL, que sólo se produce si se ha

especificado FINAL CALL para la función de tabla.

Equilibra la llamada FIRST y sólo se produce una vez por

ejecución de la sentencia. Está destinada a liberar recursos.

SQLUDF_TF_FINAL_CRA (255)

Ésta es una llamada FINAL, idéntica a la llamada FINAL

descrita antes, con una característica adicional, digamos

que está formada por UDF que están definidas como

capaces de emitir SQL, y se ha creado en un momento en

que la UDF no debe emitir SQL, a excepción de CLOSE

cursor. (SQLCODE -396, SQLSTATE 38505) Por ejemplo,

cuando DB2 está en medio de un proceso COMMIT, no

puede tolerar nuevo SQL, y cualquier llamada FINAL

emitida para una UDF en ese momento será una llamada

255 FINAL. Tenga en cuenta que las UDF que no están

definidas para contener un nivel de acceso a SQL nunca

recibirán una llamada 255 FINAL, mientras que las UDF

que utilizan SQL pueden recibir cualquier tipo de llamada

FINAL.

Liberación de recursos

Escriba las rutinas de forma que liberen los recursos que adquieran. Para

las funciones de tabla, existen dos lugares naturales para esta liberación: la

llamada CLOSE y la llamada FINAL. La llamada CLOSE equilibra cada

llamada OPEN y se puede producir varias veces en la ejecución de una

sentencia. La llamada FINAL sólo se produce si se especifica FINAL CALL

para la UDF, y únicamente se produce una vez por sentencia.

Si puede aplicar un recurso en todas las secuencias de

OPEN/FETCH/CLOSE de la UDF, escriba la UDF de forma que adquiera

el recurso en la llamada FIRST y lo libere en la llamada FINAL. El área

reutilizable es un lugar natural para hacer un seguimiento de este recurso.

Para las funciones de tabla, si se especifica FINAL CALL, el área


reutilizable sólo se inicializa antes de la llamada FIRST. Si no se especifica

FINAL CALL, se reinicializa antes de cada llamada OPEN.

Si un recurso es específico para cada secuencia de OPEN/FETCH/CLOSE,

escriba la UDF de forma que libere el recurso en la llamada CLOSE.

Nota: Cuando una función de tabla está en una subconsulta o unión, es

muy posible que se produzcan varias apariciones de la secuencia de

OPEN/FETCH/CLOSE, según cómo decida organizar la ejecución

de la sentencia el Optimizador de DB2.

El tipo-llamada toma la forma de un valor INTEGER. DB2 alinea los datos

para tipo-llamada en función del tipo de datos y del sistema operativo del

servidor.

dbinfo DB2 establece este argumento antes de llamar a la rutina. Sólo está

presente si la sentencia CREATE para la rutina especifica la palabra clave

DBINFO. El argumento es la estructura sqludf_dbinfo definida en el

archivo de cabecera sqludf.h. Las variables de esta estructura que

contienen nombres e identificadores pueden ser más largas que el valor

más largo posible en este release de DB2, pero se definen de esta manera a

efectos de compatibilidad con releases futuros. Puede utilizar la variable de

longitud que complementa cada variable de nombre y de identificador

para leer o extraer la porción de la variable que se utilice realmente. La

estructura dbinfo contiene los elementos siguientes:

1. Longitud del nombre de base de datos (dbnamelen)

Longitud del nombre de base de datos siguiente. Este campo es un entero

corto sin signo.

2. Nombre de base de datos (dbname)

Nombre de la base de datos conectada actualmente. Este campo es un

identificador largo de 128 caracteres. El campo longitud del nombre de

base de datos descrito anteriormente identifica la longitud real de este

campo. No contiene un terminador nulo ni ningún relleno.

3. Longitud del ID de autorización de la aplicación (authidlen)

Longitud del ID de autorización de la aplicación siguiente. Este campo es

un entero corto sin signo.

4. ID de autorización de la aplicación (authid)

ID de autorización de ejecución de la aplicación. Este campo es un

identificador largo de 128 caracteres. No contiene un terminador nulo

ni ningún relleno. El campo longitud del ID de autorización de la

aplicación descrito anteriormente identifica la longitud real de este

campo.

5. Páginas de códigos del entorno (codepg)

Se trata de una unión de tres estructuras de 48 bytes; una es común

para todos los productos de la base de datos DB2 (cdpg_db2), otra se

utiliza en las rutinas escritas para versiones anteriores de la base de

datos DB2 (cdpg_cs) y la última se utiliza en versiones anteriores de

DB2 UDB para z/OS y OS/390 (cdpg_mvs). Con miras a la

portabilidad, es recomendable que la estructura común, cdpg_db2, se

utilice en todas las rutinas.

La estructura cdgp_db2 está formada por una matriz

(db2_ccsids_triplet) de tres conjuntos de información de página de

códigos que representa los esquemas de codificación posibles de la

base de datos del modo siguiente:


a. Esquema de codificación ASCII. Tenga en cuenta que, para

mantener la compatibilidad con la versión anterior de la base de

datos DB2, si la base de datos es Unicode, la información

correspondiente al esquema de codificación Unicode se colocará

aquí, además de aparecer en el tercer elemento.

b. Esquema de codificación EBCDIC

c. Esquema de codificación Unicode

Después de la información de los esquemas de codificación, se

encuentra el índice de matriz del esquema de codificación para la

rutina (db2_encoding_scheme).

Cada elemento de la matriz está compuesto por tres campos:

v db2_sbcs. Página de códigos de un solo byte, un entero largo sin

signo.

v db2_dbcs. Página de códigos de doble byte, un entero largo sin

signo.

v db2_mixed. Página de códigos compuesta (también conocida como

página de códigos mixta), un entero largo sin signo. 6. Longitud del nombre de esquema (tbschemalen)

Longitud del nombre del esquema siguiente. Contiene 0 (cero) si no se

pasa un nombre de tabla. Este campo es un entero corto sin signo.

7. Nombre del esquema (tbschema)

Esquema del nombre de la tabla siguiente. Este campo es un


ni ningún relleno. El campo longitud del nombre de esquema descrito

anteriormente identifica la longitud real de este campo.

8. Longitud del nombre de tabla (tbnamelen)

Longitud del nombre de la tabla siguiente. Contiene 0 (cero) si no se

pasa un nombre de tabla. Este campo es un entero corto sin signo.

9. Nombre de la tabla (tbname)

Nombre de la tabla que se está actualizando o insertando. Este campo

sólo se establece si la referencia a la rutina se encuentra a la derecha

de una cláusula SET de una sentencia UPDATE o si es un elemento de

la lista VALUES de una sentencia INSERT. Este campo es un


ni ningún relleno. El campo longitud del nombre de tabla descrito

anteriormente identifica la longitud real de este campo. El campo

nombre del esquema descrito anteriormente forma, junto con este campo,

el nombre de tabla completamente calificado.

10. Longitud del nombre de columna (colnamelen)

Longitud del nombre de columna siguiente. Contiene un 0 (cero) si no

se pasa un nombre de columna. Este campo es un entero corto sin

signo.

11. Nombre de la columna (colname)

Bajo las mismas condiciones exactas que se aplican al nombre de la

tabla, este campo contiene el nombre de la columna que se ha de

actualizar o insertar; de lo contrario, es imprevisible. Este campo es un


ni ningún relleno. El campo longitud del nombre de columna descrito

anteriormente identifica la longitud real de este campo.

12. Número de versión/release (ver_rel)


Campo de 8 caracteres que identifica el producto y la versión, el

release y el nivel de modificación del mismo, con el formato pppvvrrm,

donde:

v ppp identifica el producto, del modo siguiente:

DSN DB2 Universal Database para z/OS o OS/390

ARI SQL/DS o DB2 para VM o VSE

QSQ DB2 Universal Database para iSeries

SQL DB2 Database para Linux, UNIX y Windowsv vv es un identificador de versión de dos dígitos.

v rr es un identificador de release de dos dígitos.

v m es un identificador de nivel de modificación de un dígito.13. Campo reservado (resd0)

Este campo es para usos futuros.

14. Plataforma (platform)

Sistema operativo (plataforma) del servidor de aplicaciones, tal como

se indica a continuación:

SQLUDF_PLATFORM_AIX AIX

SQLUDF_PLATFORM_HP HP-UX

SQLUDF_PLATFORM_LINUX

Linux

SQLUDF_PLATFORM_MVS OS/390

SQLUDF_PLATFORM_NT Windows 2000, Windows XP

SQLUDF_PLATFORM_SUN Sistema operativo Solaris

SQLUDF_PLATFORM_WINDOWS95

Windows 95, Windows 98, Windows

Me

SQLUDF_PLATFORM_UNKNOWN

Plataforma o sistema operativo

desconocidoPara informarse sobre sistemas operativos adicionales no incluidos en

la lista anterior, consulte el contenido del archivo sqludf.h.

15. Número de entradas de la lista de columnas de la función de tabla

(numtfcol)

Número de entradas distintas de cero que existen en la lista de

columnas de la función de tabla especificada en el campo lista de

columnas de la función de tabla siguiente.

16. Campo reservado (resd1)


17. ID de rutina del procedimiento almacenado que ha invocado la rutina

actual (procid)

El ID de rutina del procedimiento almacenado coincide con la

columna ROUTINEID de SYSCAT.ROUTINES, que se puede utilizar

para recuperar el nombre del procedimiento almacenado que realiza la

invocación. Este campo es un entero con signo de 32 bits.



19. Lista de columnas de la función de tabla (tfcolumn)

Si ésta es una función de tabla, este campo es un puntero a una matriz

de enteros cortos que DB2 asigna dinámicamente. Si se trata de

cualquier otro tipo de rutina, este puntero es nulo.

Sólo se utiliza este campo para las funciones de tabla. Sólo son de

interés las n primeras entradas, donde n se especifica en el campo


número de entradas de la lista de columnas de la función de tabla, numtfcol.

n puede equivaler a 0, y n es inferior o igual al número de columnas

de resultado definidas para la función en la cláusula RETURNS

TABLE(...) de la sentencia CREATE FUNCTION. Los valores

corresponden a los números ordinales de las columnas que esta

sentencia necesita de la función de tabla. Un valor de ‘1’ significa la

primera columna de resultado definida, ‘2’ significa la segunda

columna de resultado definida, y así sucesivamente, y los valores

pueden seguir cualquier orden. Tenga en cuenta que n puede ser igual

a cero, es decir, que la variable numtfcol puede ser cero, para una

sentencia parecida a SELECT COUNT(*) FROM TABLE(TF(...)) AS QQ, en

que la consulta no necesita ningún valor de columna real.

Esta matriz representa una oportunidad para realizar una

optimización. La UDF no tiene necesidad de devolver todos los

valores de todas las columnas de resultado de la función de tabla,

únicamente de aquéllas que sean necesarias en el contexto en concreto,

y éstas son las columnas identificadas (por número) en la matriz.

Dado que esta optimización puede complicar la lógica de la UDF para

lograr beneficios en el rendimiento, la UDF puede elegir devolver

todas las columnas definidas.

20. Identificador exclusivo de la aplicación (appl_id)

Este campo es un puntero a una serie C terminada en nulo que

identifica de forma exclusiva la conexión de la aplicación con DB2.

DB2 lo genera durante la conexión.

La serie tiene una longitud máxima de 32 caracteres y su formato

exacto depende del tipo de conexión establecida entre el cliente y DB2.

Generalmente, toma la forma siguiente:

x.y.ts

donde x e y varían según el tipo de conexión, pero ts es una

indicación de la hora de 12 caracteres con formato

AAMMDDHHMMSS, que DB2 ajusta potencialmente para asegurar su

exclusividad.

Ejemplo: *LOCAL.db2inst.980707130144








v “appl_id - Application ID monitor element” en System Monitor Guide and

Reference






Variables gráficas del lenguaje principal en rutinas C y C++

Generalmente, cualquier rutina escrita en C o C++ que reciba o devuelva datos

gráficos a través de su entrada o salida de parámetros se debe precompilar con la

opción WCHARTYPE NOCONVERT. Esto es debido a que los datos gráficos que

se pasan mediante dichos parámetros se considera que están en formato DBCS, en

lugar del formato de código de procesos wchar_t. La utilización de NOCONVERT

significa que los datos gráficos manipulados en sentencias de SQL de la rutina

también estarán en formato DBCS, coincidiendo así con el formato de los datos de

parámetros.

Con WCHARTYPE NOCONVERT, no se produce ninguna conversión del código

de caracteres entre la variable gráfica del lenguaje principal y el gestor de bases de

datos. Los datos de una variable gráfica del lenguaje principal se envían al gestor

de bases de datos y se reciben del mismo como caracteres DBCS inalterados. Si no

utiliza WCHARTYPE NOCONVERT, también podrá manipular datos gráficos en

formato wchar_t en una rutina; sin embargo, deberá realizar manualmente las

conversiones de entrada y salida.

Se puede utilizar CONVERT en las rutinas FENCED, lo que afectará a los datos

gráficos de las sentencias de SQL incluidas en la rutina, pero no a los datos

pasados a través de los parámetros de la rutina. Las rutinas NOT FENCED se

deben crear utilizando la opción NOCONVERT.

En resumen, los datos gráficos pasados a una rutina o devueltos por ésta mediante

sus parámetros de entrada o salida están en formato DBCS, independientemente de

cómo se haya precompilado con la opción WCHARTYPE.






Decoración de tipos de C++

Los nombres de las funciones de C++ se pueden sobrecargar. Pueden coexistir dos

funciones de C++ con el mismo nombre si tienen argumentos distintos, por

ejemplo:

int func( int i )

e

int func( char c )

Por omisión, los compiladores C++ decoran con tipos o ’despedazan’ los nombres

de función. Esto significa que se añaden nombres de tipo de argumento a sus

nombres de función correspondientes para resolverlos, como por ejemplo en

func__Fi y func__Fc para los dos ejemplos anteriores. Los nombres despedazados

serán distintos en cada sistema operativo, por lo que no se puede transportar el

código que utiliza explícitamente un nombre despedazado.

En los sistemas operativos Windows, el nombre de función decorado con tipos se

puede determinar a partir del archivo .obj (objeto).


Con el compilador Microsoft Visual C++ en Windows, puede utilizar el mandato

dumpbin para determinar el nombre de función decorado con tipos a partir del

archivo .obj (objeto), del modo siguiente:

dumpbin /symbols myprog.obj

donde myprog.obj es el archivo de objeto del programa.

En los sistemas operativos UNIX, el nombre de función decorado con tipos se

puede determinar a partir del archivo .o (objeto), o de la biblioteca compartida,

utilizando el mandato nm. Este mandato puede producir una salida considerable,

por lo que se le aconseja que conduzca la salida a través de grep para buscar la

línea correcta, del modo siguiente:

nm myprog.o | grep myfunc

donde myprog.o es el archivo de objeto del programa y myfunc es la función en el

archivo fuente del programa.

La salida producida por todos estos mandatos incluye una línea con el nombre de

función despedazado. Por ejemplo, en UNIX, dicha línea es parecida a la siguiente:

myfunc__FPlT1PsT3PcN35| 3792|unamex| | ...

Una vez obtenido el nombre de función despedazado de uno de los mandatos

anteriores, lo podrá utilizar en el mandato apropiado. Esto se muestra más

adelante en este apartado al utilizar el nombre de función despedazado que se ha

obtenido en el ejemplo de UNIX anterior. Un nombre de función despedazado

obtenido en Windows se utilizaría de la misma manera.

Cuando se registra una rutina con la sentencia CREATE, la cláusula EXTERNAL

NAME debe especificar el nombre de función despedazado. Por ejemplo:

CREATE FUNCTION myfunco(...) RETURNS...

...

EXTERNAL NAME ’/whatever/path/myprog!myfunc__FPlT1PsT3PcN35’

...

Si la biblioteca de rutinas no contiene nombres de funciones de C++ sobrecargados,

existe la opción de utilizar extern "C" para hacer que el compilador no decore con

tipos los nombres de función. (Tenga en cuenta que siempre puede sobrecargar los

nombres de función de SQL asignados a las UDF, ya que DB2 resuelve qué función

de biblioteca debe invocar basándose en el nombre y los parámetros que toma.)


En este ejemplo, el compilador no decora con tipos las UDF fold y findvwl, que se

deben registrar en la sentencia CREATE FUNCTION utilizando sus nombres

llanos. De forma similar, si un método o procedimiento almacenado C++ se

codifica con extern "C", se utilizará su nombre de función no decorado en la

sentencia CREATE.


v “Manejo de parámetros en procedimientos PROGRAM TYPE MAIN o

PROGRAM TYPE SUB” en Desarrollo de SQL y rutinas externas


Devolución de conjuntos de resultados desde procedimientos C

y C++

Puede desarrollar procedimientos C y C++ que devuelvan conjuntos de resultados

a una rutina o aplicación llamadora implementada mediante una API que permita

recuperar conjuntos de resultados de procedimientos. La mayoría de las API

permiten recuperar conjuntos de resultados de procedimientos, pero no en el caso

de SQL incorporado.

La representación C y C++ de un conjunto de resultados es un cursor SQL.

Cualquier cursor SQL que se haya declarado y abierto, pero no explícitamente

cerrado dentro de un procedimiento, antes del retorno del procedimiento se puede

devolver al llamador. El orden en que se devuelven los conjuntos de resultados al

llamador coincide con el orden en que los objetos cursor se abren dentro de la

rutina. No se necesitan parámetros adicionales en la sentencia CREATE

PROCEDURE ni en la implementación del procedimiento para devolver un

conjunto de resultados.

#include <string.h>

#include <stdlib.h>

#include "sqludf.h"

/*---------------------------------------------------------------------*/

/* función fold: salida = la serie de entrada se dobla en el punto */

/* indicado por el segundo argumento. */

/* entradas: CLOB, serie de entrada */

/* LONG posición por la que doblar */

/* salida: CLOB serie doblada */

/*---------------------------------------------------------------------*/

extern "C" void fold(

SQLUDF_CLOB *in1, /* entrada CLOB a doblar */

...

...

}

/* fin de UDF: fold */

/*---------------------------------------------------------------------*/

/* función find_vowel: */

/* devuelve la posición de la primera vocal */

/* devuelve un error si no hay ninguna vocal */

/* definida como NOT NULL CALL */

/* entradas: VARCHAR(500) */

/* salida: INTEGER */

/*---------------------------------------------------------------------*/

extern "C" void findvwl(

SQLUDF_VARCHAR *in, /* entrada smallint */

...

...

}

/* fin de UDF: findvwl */


Prerrequisitos:

Un conocimiento general de cómo se crean las rutinas C y C++ le ayudará a seguir

los pasos del procedimiento que figura más abajo para devolver resultados de un

procedimiento C o C++.

Creación de rutinas C y C++

Los cursores declarados en procedimientos de SQL incorporado en C o C++ no son

cursores desplazables.

Procedimiento:

Para devolver un conjunto de resultados de un procedimiento C o C++:

1. En la sentencia CREATE PROCEDURE del procedimiento C o C++, debe

especificar, junto con cualquier otra cláusula pertinente, la cláusula DYNAMIC

RESULT SETS con un valor igual al número máximo de conjuntos de

resultados que debe devolver el procedimiento.

2. Los marcadores de parámetros no son necesarios en la declaración de un

procedimiento para un conjunto de resultados que se va a devolver al llamador.

3. En la implementación de procedimiento C o C++ de la rutina, declare un cursor

mediante la sentencia DECLARE CURSOR en la sección de declaraciones en las

que se declaran las variables del lenguaje principal. La declaración del cursor

asocia un SQL al cursor.

4. Dentro del código de la rutina C o C++, abra el cursor ejecutando la sentencia

OPEN. Con ello se ejecuta la consulta especificada en la sentencia DECLARE

CURSOR, y el resultado de la consulta se asocia al cursor.

5. Opcional: capte filas del conjunto de resultados asociado al cursor mediante la

sentencia FETCH.

6. No ejecute la sentencia CLOSE que sirve para cerrar el cursor en ningún

momento anterior al retorno del procedimiento al llamador. El cursor abierto se

devolverá como conjunto de resultados al llamador cuando el procedimiento

retorne.

Cuando se deja abierto más de un cursor después del retorno de un

procedimiento, los conjuntos de resultados asociados a los cursores se

devuelven al llamador en el orden en que se abrieron. Con el procedimiento no

se pueden devolver más del número máximo de conjuntos de resultados

especificados por el valor de la cláusula DYNAMIC RESULT SETS. Si el

número de cursores que se han dejado abiertos en la implementación del

procedimiento es mayor que el valor especificado por la cláusula DYNAMIC

RESULT SETS, los conjuntos de resultados en exceso no se devuelven. Cuando

se da esta situación, DB2 no indica ningún mensaje de error o aviso.

Una vez que la creación del procedimiento C o C++ se ha completado

satisfactoriamente, ya se puede invocar el procedimiento con la sentencia CALL

desde el procesador de línea de mandatos (CLP) de DB2 o desde una ventana de

mandatos de DB2 para verificar que los conjuntos de resultados se han devuelto

satisfactoriamente al llamador.

Si desea obtener información sobre la llamada a procedimientos y otros tipos de

rutinas:

v Invocación de la rutina


Consideraciones sobre la precompilación y vinculación para

rutinas de SQL incorporado

Concept text

Creación de rutinas C y C++

Los procedimientos y funciones que hacen referencia a una biblioteca C o C++ se

crean de forma similar a las rutinas externas con otras implementaciones. Esta

tarea comprende unos pasos, incluida la formulación de la sentencia CREATE para

la rutina, la codificación de la implementación de la rutina, la precompilación, la

compilación y enlace de código, y el despliegue de código fuente.

Elegirá implementar una rutina C o C++ si:

v Desea encapsular lógica compleja en una rutina que acceda a la base de datos o

que realice una acción fuera de la base de datos.

v Necesita que la lógica encapsulada se invoque desde cualquiera de estos

elementos: diversas aplicaciones, el CLP, otra rutina (procedimiento, función

(UDF) o método) o un activador.

v Se siente más cómodo codificando este lógica con lenguaje de programación de

SQL incorporado como C o C++.

Requisitos previos:

v Conocimiento de la implementación de rutinas C y C++. Para obtener

información sobre las rutinas C y C++ en general, consulte:

– Rutinas C y C++ “Rutinas C y C++” en la página 314v El Cliente DB2, que incluye el soporte de desarrollo de aplicaciones debe estar

instalado en el sistema cliente.

v El servidor de bases de datos debe ejecutar un sistema operativo que dé soporte

a un compilador C o C++ soportado de DB2 para el desarrollo de rutinas.

v Los compiladores necesarios deben estar instalados en el servidor de base de

datos.

v Autorización para ejecutar la sentencia CREATE correspondiente a la rutina

externa. Si desea saber cuáles son los privilegios necesarios para ejecutar la

sentencia CREATE PROCEDURE o la sentencia CREATE FUNCTION, consulte

la documentación de la sentencia.

Procedimiento:

1. Codifique la lógica de la rutina en el lenguaje de programación elegido: C o

C++.

v Para obtener información general sobre rutinas C y C++ y características de

las rutinas C y C++, consulte los temas a los que se hace referencia en la

sección Requisitos previos.

v Incluya los archivos de cabecera de C o C++ necesarios para funciones

adicionales de C, así como los archivos de cabecera de C o C++ de DB2

necesarios para el tipo de datos de SQL y el soporte de ejecución de SQL.

Incluya los siguientes archivos de cabecera: sqludf.h, sql.h, sqlda.h, sqlca.h y

memory.h.

v Debe implementarse una signatura de parámetro de rutina utilizando uno de

los estilos de parámetros soportados. Se recomienda utilizar el estilo de

parámetros SQL para todas las rutinas C y C++. Las áreas reutilizables y las


estructuras dbinfo se pasan a las rutinas C y C++ como parámetros. Si desea

más información sobre las signaturas de parámetros y las implementaciones

de parámetros, consulte:

– “Parámetros de rutinas C y C++” en la página 319

– “Estilo de parámetros SQL en procedimientos C y C++” en la página 320

– “Estilo de parámetros SQL en procedimientos C y C++” en la página 320v Declare variables del lenguaje principal y marcas de parámetros de la misma

manera que se hace para las aplicaciones C y C++ de SQL incorporado.

Utilice correctamente los tipos de datos que se correlacionan con tipos de

datos de SQL de DB2. Para obtener más información sobre la correlación de

tipos de datos entre DB2 y C o C++, consulte:

– Tipos de datos de SQL soportados en aplicaciones y rutinas C y C++v Incluya la lógica de la rutina. La lógica de la rutina puede constar de

cualquier código soportado en el lenguaje de programación C o C++.

También puede incluir la ejecución de sentencias de SQL incorporado, que se

implementan de la misma manera que para las aplicaciones de SQL

incorporado. Para obtener más información sobre la ejecución de sentencias

de SQL en SQL incorporado, consulte:

– ″Ejecución de sentencias de SQL en aplicaciones de SQL incorporado″

v Si la rutina es un procedimiento y desea devolver un conjunto de resultados

al llamador de la rutina, no es necesario ningún parámetro para el conjunto

de resultados. Si desea más información sobre la devolución de conjuntos de

resultados desde rutinas:

– Devolución de conjuntos de resultados procedentes de procedimientos C y

C++v Establezca un valor de retorno de rutina al final de la rutina.

2. Construya el código para generar un archivo de biblioteca. Para obtener

información sobre cómo crear rutinas C y C++ de SQL incorporado, consulte:

v “Creación del código de rutinas C y C++” en la página 3623. Copie la biblioteca al directorio de función de DB2 del servidor de bases de

datos. Es recomendable almacenar las bibliotecas asociadas con rutinas de DB2

en el directorio de función. Para conocer más acerca del directorio de función,

consulte la cláusula EXTERNAL de una de las sentencias siguientes: CREATE

PROCEDURE o CREATE FUNCTION.

Puede copiar la biblioteca en otro directorio del servidor, pero para invocar la

rutina satisfactoriamente, debe anotar el nombre de la vía de acceso totalmente

calificada de la biblioteca, ya que lo necesitará en el paso siguiente.

4. Ejecute de forma dinámica o estática la sentencia CREATE de lenguaje SQL

correspondiente para el tipo de rutina: CREATE PROCEDURE o CREATE

FUNCTION.

v Especifique la cláusula LANGUAGE con el valor: C

v Especifique la cláusula PARAMETER STYLE con el nombre del estilo de

parámetros soportado que se ha implementado en el código de la rutina. Se

recomienda utilizar PARAMETER STYLE SQL.

v Especifique la cláusula EXTERNAL con el nombre de la biblioteca que se ha de

asociar con la rutina utilizando uno de los valores siguientes:

– el nombre de vía de acceso completamente calificado de la biblioteca de

rutina

– el nombre de vía de acceso relativo de la biblioteca de rutina en relación

con el directorio de función.


Por omisión, DB2 buscará la biblioteca en el directorio de función, a menos

que se especifique un nombre de vía de acceso completamente calificado o

relativo para la biblioteca en la cláusula EXTERNAL.

v Especifique DYNAMIC RESULT SETS con un valor numérico si la rutina es

un procedimiento y ha de devolver uno o varios conjunto de resultados al

llamador.

v Especifique otros valores de cláusula no por omisión en la sentencia CREATE

a utilizar para caracterizar la rutina.

Para invocar la rutina C o C++, consulte Invocación de la rutina





v “Invocación de rutinas” en Desarrollo de SQL y rutinas externas






Creación del código de rutinas C y C++

Creación del código de rutinas C y C++

Una vez se ha escrito el código de implementación de una rutina C o C++ de SQL

incorporado, se debe incorporar en una biblioteca y desplegar para que se pueda

invocar la rutina. Aunque los pasos a seguir para crear rutinas C y C++ de SQL

incorporado son parecidos a los necesarios para crear aplicaciones C y C++ de SQL

incorporado, hay algunas diferencias. Los mismos pasos se pueden seguir si no

hay sentencias de SQL incorporado dentro de las rutinas; el procedimiento será

más rápido y sencillo.

Hay dos formas de crear rutinas C y C++:

v Mediante scripts de creación de ejemplo de DB2 (UNIX) o archivos de proceso

por lotes de creación (Windows)

v Especificando mandatos del compilador de DB2 y C o C++ desde una ventana

de mandatos de DB2

Los scripts de creación de ejemplo de DB2 y los archivos de proceso por lotes

correspondientes a rutinas están diseñados para crear rutinas de ejemplo de DB2

(procedimientos y funciones definidas por el usuario), así como rutinas creadas por

el usuario para un determinado sistema operativo utilizando los compiladores

soportados por omisión.

Hay un conjunto separado de scripts de creación de ejemplo de DB2 y de archivos

de proceso por lotes para C y C++. En general, es más fácil crear rutinas de SQL

incorporado utilizando los scripts de creación o los archivos de proceso por lotes,

que se pueden modificar fácilmente si hace falta; sin embargo, suele resultar útil

saber cómo crear rutinas desde ventanas de mandatos de DB2.


Para obtener más información sobre cada uno de los métodos para crear rutinas,

consulte los enlaces relacionados.



página 210


v “Almacenamiento y mantenimiento de paquetes” en la página 219



v “Creación de código de rutinas C y C++ desde ventanas de mandatos de DB2”

en la página 371

v “Creación de código de rutinas C y C++ mediante scripts bldrtn de ejemplo” en

la página 363



página 391




la página 392

v “Opciones de compilación y enlace para rutinas C y C++ de Windows” en la

página 384


página 395



Creación de códigos de rutinas C y C++ mediante el scripts

bldrtn de ejemplo

Creación de código de rutinas C y C++ mediante scripts bldrtn de ejemplo: La

creación de código fuente de rutinas C y C++ es una subtarea de la creación de

rutinas C y C++. Esta tarea se puede realizar de forma rápida y fácil mediante los

scripts de creación de ejemplo (UNIX) y los archivos de proceso por lotes

(Windows) de DB2. Los scripts de creación de ejemplo se pueden utilizar para el

código fuente con o sin sentencias de SQL incorporado. Los scripts de creación se

ocupan de la precompilación, compilación y enlace del código fuente C y C++, que

de otro modo se tiene que hacer con pasos individuales desde la línea de

mandatos. También se ocupan de vincular cualquier paquete a la base de datos

especificada.

Los scripts de creación de ejemplo para crear rutinas C y C++ se denominan

bldrtn. Se encuentran en directorios de DB2 junto con los programas de ejemplo

que se pueden crear con ellos, en las siguientes ubicaciones:

v Para C: sqllib/samples/c/

v Para C++: sqllib/samples/cpp/

El script bldrtn se puede utilizar para crear un archivo de código fuente que

contenga implementaciones de procedimientos y funciones. El script hace lo

siguiente:


v Establece una conexión con una base de datos especificada por el usuario

v Precompila el archivo de código fuente especificado por el usuario

v Vincula el paquete con la base de datos actual

v Compila y enlaza el código fuente para generar una biblioteca compartida

v Copia la biblioteca compartida en el directorio de función de DB2 en el servidor

de bases de datos

Los scripts bldrtn aceptan dos argumentos:

v El nombre de un archivo de código fuente sin extensión de archivo

v El nombre de una base de datos con la que se establecerá una conexión

El parámetro correspondiente a la base de datos es opcional. Si no se proporciona

un nombre de base de datos, el programa utiliza la base de datos por omisión

sample. Puesto que las rutinas se tienen que crear en la misma instancia en la que

reside la base de datos, no se necesitan argumentos para ID de usuario y

contraseña.

Requisitos previos:

v Archivo de código fuente que contenga una o más implementaciones de rutina.

v El nombre de la base de datos dentro de la instancia de DB2 actual en la que se

van a crear las rutinas.

Procedimiento:

Para crear un archivo de código fuente que contenga una o más implementaciones

de código de rutina, siga los pasos siguientes.

1. Abra una ventana de mandatos de DB2.

2. Copie el archivo de código fuente en el mismo directorio que el script bldrtn.

3. Si las rutinas se van a crear en la base de datos sample, especifique el nombre

del script de creación seguido del nombre del archivo de código fuente sin la

extensión de archivo .sqc o .sqC.

bldrtn <nombre-archivo>

Si las rutinas se van a crear en otra base de datos, especifique el nombre del

script de creación, el nombre del archivo de código fuente sin extensión de

archivo y el nombre de la base de datos:

bldrtn <nombre-archivo> <nombre-basedatos>

El script precompila, compila y enlaza el código fuente y genera una biblioteca

compartida. Luego el script copia la biblioteca compartida en el directorio de

función en el servidor de bases de datos.

4. Si no es la primera vez que se crea el archivo de código fuente que contiene las

implementaciones de rutinas, detenga y vuelva a iniciar la base de datos para

asegurarse de que DB2 utiliza la nueva versión de la biblioteca compartida.

Puede hacerlo especificando db2stop seguido de db2start en la línea de

mandatos.

Cuando haya creado satisfactoriamente la biblioteca compartida de rutinas y la

haya desplegado en el directorio de función en el servidor de bases de datos, debe

completar los pasos asociados a la tarea de crear rutinas C y C++. Una vez

completada la creación de rutinas, podrá invocar las rutinas.








página 391


la página 392


página 384


página 395

Creación de rutinas en C o C++ mediante el script de creación de ejemplo

(UNIX): DB2 proporciona scripts de creación para compilar y enlazar programas

en C y C++. Se encuentran en el directorio sqllib/samples/c para rutinas en C y

en el directorio sqllib/samples/cpp para rutinas en C++, junto con programas de

ejemplo que se pueden crear con estos archivos.

El script bldrtn contiene los mandatos para crear rutinas (procedimientos

almacenados y funciones definidas por el usuario). El script compila la rutina y

crea una biblioteca compartida que puede ser cargada por el gestor de bases de

datos y llamada por una aplicación cliente.

El primer parámetro, $1, especifica el nombre del archivo fuente. El segundo

parámetro, $2, especifica el nombre de la base de datos a la que desea conectarse.

El parámetro correspondiente a la base de datos es opcional. Si no se proporciona

un nombre de base de datos, el programa utiliza la base de datos por omisión

sample. Debido a que el procedimiento almacenado se debe crear en la misma

instancia donde reside la base de datos, no hay parámetros para el ID de usuario

ni la contraseña.

Procedimiento:

Los ejemplos siguientes muestran cómo crear bibliotecas compartidas de rutinas

mediante:

v procedimientos almacenados

v funciones definidas por el usuario (UDF) de SQL no incorporado

v funciones definidas por el usuario (UDF) de SQL incorporado

Biblioteca compratida de procedimientos almacenados

Puede crear el programa de ejemplo spserver a partir del archivo fuente

spserver.sqc para C y spserver.sqC para C++:

1. Si conecta con la base de datos sample, especifique el nombre del script de

creación y el nombre del programa:

bldrtn spserver

Si conecta con otra base de datos, especifique también el nombre de la base de

datos:

bldrtn spserver basedatos


El script copia la biblioteca compartida en el directorio sqllib/function del

servidor.

2. A continuación, catalogue las rutinas ejecutando el script spcat en el servidor:

spcat

Este script conecta con la base de datos ″sample″, descataloga mediante

spdrop.db2 las rutinas que se hubieran catalogado previamente, luego las

cataloga llamando a spcreate.db2, y finalmente desconecta de la base de datos.

Puede también ejecutar los scripts spdrop.db2 y spcreate.db2 por separado.

3. A continuación, si no es la primera vez que se crea el procedimiento

almacenado, detenga y reinicie la base de datos para asegurarse que se

reconoce la nueva versión de la biblioteca compartida. Lo puede hacer entrando

en la línea de mandatos db2stop seguido de db2start.

Una vez creada la biblioteca compartida, spserver, puede crear la aplicación

cliente, spclient, la cual accede a la biblioteca compartida.

Puede crear spclient utilizando el archivo de script, bldapp.

Para invocar los procedimientos almacenados en la biblioteca compartida, ejecute

la aplicación cliente de ejemplo, especificando lo siguiente: spclient basedatos

IDusuario contraseña

donde

basedatos

Es el nombre de la base de datos a la que desea conectarse. El nombre

podría ser sample, o su alias, u otro nombre de base de datos.

IDusuario

Es un ID de usuario válido.

contraseña

Es una contraseña válida correspondiente al ID de usuario.

La aplicación cliente accede a la biblioteca compartida, spserver, y ejecuta diversas

funciones de procedimiento almacenado en la base de datos del servidor. Los datos

resultantes se devuelven a la aplicación cliente.

Biblioteca compartida de UDF de SQL incorporado

Puede crear el programa de función definida por el usuario de SQL incorporado,

udfemsrv, a partir del archivo fuente udfemsrv.sqc para C y udfemsrv.sqC para

C++. Si conecta con la base de datos sample, especifique el nombre del script de

creación y el nombre del programa:

bldrtn udfemsrv


datos:

bldrtn udfemsrv basedatos

El script copia la UDF en el directorio sqllib/function.


Una vez creado el programa udfemsrv, puede crear la aplicación cliente, udfemcli,

que llama al programa. Puede crear el programa cliente udfemcli a partir del

archivo fuente udfemcli.sqc, contenido en sqllib/samples/c, utilizando el script

bldapp.

Para invocar las UDF de la biblioteca compartida, ejecute la aplicación cliente,

especificando lo siguiente: udfemcli basedatos IDusuario contraseña

donde

basedatos



IDusuario


contraseña


La aplicación cliente accede a la biblioteca compartida, udfemsrv, y ejecuta las

funciones definidas por el usuario contenidas en la base de datos del servidor. Los

datos resultantes se devuelven a la aplicación cliente.









v “Opciones de compilación y enlace para rutinas C de HP-UX” en la página 376

v “Opciones de compilación y enlace para rutinas C de Linux” en la página 378

v “Opciones de compilación y enlace para rutinas C de Solaris” en la página 381


v “bldrtn -- Builds AIX C routines (stored procedures and UDFs) (C)”

v “bldrtn -- Builds HP-UX C routines (stored procedures and UDFs) (C)”

v “bldrtn -- Builds Linux C routines (stored procedures or UDFs) (C)”

v “bldrtn -- Builds Solaris C routines (stored procedures or UDFs) (C)”


programs (C)”


v “spserver.sqc -- Definition of various types of stored procedures (C)”

v “udfemcli.sqc -- Call a variety of types of embedded SQL user-defined functions.

(C)”

v “udfemsrv.sqc -- Call a variety of types of embedded SQL user-defined

functions. (C)”

Creación de rutinas C/C++ en Windows: DB2 proporciona scripts de creación

para compilar y enlazar programas de la API de DB2 y de SQL incorporado en C y


C++. Estos archivos residen en los directorios sqllib/samples/c y

sqllib\samples\cpp, junto con programas de ejemplo que se pueden crear a partir

de esos archivos.

El archivo de proceso por lotes bldrtn.bat contiene los mandatos para crear

rutinas (procedimientos almacenados y funciones definidas por el usuario) de SQL

incorporado. El archivo de proceso por lotes crea una DLL en el servidor. Utiliza

dos parámetros como entrada, que están representados dentro del archivo de

proceso por lotes por las variables %1 y %2.

El primer parámetro, %1, especifica el nombre del archivo fuente. El archivo de

proceso por lotes utiliza el nombre del archivo fuente para el nombre de la DLL El

segundo parámetro, %2, especifica el nombre de la base de datos a la que desea

conectarse. Debido a que la DLL se debe crear en la misma instancia donde reside

la base de datos, no hay parámetros para el ID de usuario ni la contraseña.

Sólo es obligatorio el primer parámetro, el nombre del archivo fuente. El nombre

de la base de datos es opcional. Si no se proporciona un nombre de base de datos,

el programa utiliza la base de datos por omisión sample.

Procedimiento:

Los ejemplos siguientes muestran cómo crear las DLL de rutinas mediante:

v procedimientos almacenados

v funciones definidas por el usuario (UDF) de SQL no incorporado

v funciones definidas por el usuario (UDF) de SQL incorporado

DLL de procedimiento almacenado

Para crear la DLL spserver a partir del archivo fuente C, spserver.sqc, o a partir

del archivo fuente C++, spserver.sqx:

1. Escriba el nombre del archivo de proceso por lotes y el nombre del programa:

bldrtn spserver


datos:

bldrtn spserver basedatos

El archivo de proceso por lotes utiliza el archivo de definición de módulos,

spserver.def, que reside en el mismo directorio que los programas de ejemplo,

para crear la DLL. El archivo de proceso por lotes copia la DLL, spserver.dll,

en el directorio sqllib\function del servidor.

2. A continuación, catalogue las rutinas ejecutando el script spcat en el servidor:

spcat

Este script conecta con la base de datos ″sample″, descataloga mediante

spdrop.db2 las rutinas que se hubieran catalogado previamente, luego las



3. A continuación, detenga y rearranque la base de datos para que se reconozca la

nueva DLL. Si es necesario, establezca la modalidad de archivo para la DLL a

fin de que la instancia de DB2 pueda acceder a la DLL.


Una vez creada la DLL, spserver, puede crear la aplicación cliente spclient, la

cual accede a la DLL.

Puede crear spclient utilizando el archivo de proceso por lotes, bldapp.bat.

Para invocar la DLL, ejecute la aplicación cliente de ejemplo, especificando lo

siguiente:

spclient basedatos IDusuario contraseña

donde

basedatos



IDusuario


contraseña


La aplicación cliente accede a la DLL, spserver, la cual ejecuta varias rutinas

contenidas en la base de datos del servidor. Los datos resultantes se devuelven a la

aplicación cliente.

DLL de funciones definidas por el usuario de SQL no incorporado

Para crear la función definida por el usuario udfsrv a partir del archivo fuente

udfsrv.c, especifique:

bldrtn udfsrv


udfsrv.def, que reside en el mismo directorio que los programas de ejemplo, para

crear la DLL de función definida por el usuario. El archivo de proceso por lotes

copia la DLL de función definida por el usuario, udfsrv.dll, en el directorio

sqllib\function del servidor.

Una vez creado el programa udfsrv, puede crear la aplicación cliente, udfcli, la

cual llama al programa. Se proporcionan versiones en C y C++ de este programa

para la CLI de DB2 y de SQL incorporado.

Puede crear el programa udfcli de la CLI de DB2 a partir del archivo fuente

udfcli.c situado en sqllib\samples\cli utilizando el archivo de proceso por lotes

bldapp.

Puede crear el programa en C udfcli de SQL incorporado a partir del archivo

fuente udfcli.sqc, situado en sqllib\samples\c, utilizando el archivo de proceso

por lotes bldapp.

Puede crear el programa en C++ udfcli de SQL incorporado a partir del archivo

fuente udfcli.sqx, situado en sqllib\samples\cpp, utilizando el archivo de proceso

por lotes bldapp.

Para ejecutar la UDF (función definida por el usuario), especifique:

udfcli


La aplicación solicitante llama a la función ScalarUDF de la DLL udfsrv.

DLL de UDF de SQL incorporado

Para crear la biblioteca de función definida por el usuario de SQL incorporado

udfemsrv, a partir del archivo fuente C udfemsrv.sqc de sqllib\samples\c, o a

partir del archivo C++ udfemsrv.sqx de sqllib\samples\cpp, especifique:

bldrtn udfemsrv


datos:

bldrtn udfemsrv basedatos


udfemsrv.def, que reside en el mismo directorio que los programas de ejemplo,

para crear la DLL de función definida por el usuario. El archivo de proceso por

lotes copia la DLL de función definida por el usuario, udfemsrv.dll, en el

directorio sqllib\function del servidor.

Una vez creado el programa udfemsrv, puede crear la aplicación cliente, udfemcli,

que llama al programa. Puede crear udfemcli a partir del archivo fuente C

udfemcli.sqc de sqllib\samples\c, o a partir del archivo fuente C++ udfemcli.sqx

de sqllib\samples\cpp, utilizando el archivo de proceso por lotes bldapp.

Para ejecutar la UDF (función definida por el usuario), especifique:

udfemcli

La aplicación solicitante llama a las UDF contenidas en la DLL udfemsrv.



página 384


v “bldrtn.bat -- Builds C routines (stored procedures and UDFs) on Windows”




v “spserver.sqc -- Definition of various types of stored procedures (C)”

v “udfcli.sqc -- Call a variety of types of user-defined functions (C)”

v “udfemcli.sqc -- Call a variety of types of embedded SQL user-defined functions.

(C)”

v “udfemsrv.sqc -- Call a variety of types of embedded SQL user-defined

functions. (C)”

v “udfsrv.c -- Defines a variety of types of user-defined functions (C)”

v “bldrtn.bat -- Builds C++ routines (stored procedures and UDFs) on Windows”

v “spclient.sqC -- Call various stored procedures (C++)”

v “spserver.sqC -- Definition of various types of stored procedures (C++)”

v “udfcli.sqC -- Call a variety of types of user-defined functions (C++)”

v “udfemcli.sqC -- Call a variety of types of embedded SQL user-defined

functions. (C++)”


v “udfemsrv.sqC -- Call a variety of types of embedded SQL user-defined

functions. (C++)”

v “udfsrv.C -- Defines a variety of types of user-defined functions (C++)”

Creación de código de rutinas C y C++ desde ventanas de

mandatos de DB2

La creación de código fuente de rutinas C y C++ es una subtarea de la creación de

rutinas C y C++. Esta tarea se puede realizar de forma manual desde la línea de

mandatos. Se puede seguir el mismo procedimiento independientemente de si hay

o no sentencias de SQL incorporado dentro del código de rutinas C o C++. Los

pasos de la tarea incluyen precompilación, compilación y enlace de código fuente

C y C++ que contiene implementaciones de rutinas, vinculación del paquete

generado (si había sentencias de SQL incorporado) y despliegue de la biblioteca

compartida. Puede realizar esta tarea desde una ventana de mandatos de DB2

como parte de la prueba del uso de un precompilador, compilador u opción de

vinculación, si desea diferir la vinculación de los paquetes de la rutina hasta más

adelante o si está desarrollando scripts de creación personalizados.

Como alternativa, puede utilizar los scripts de creación de ejemplo de DB2 para

simplificar esta tarea. Consulte: Creación de código de rutinas C y C++ de SQL

incorporado mediante scripts de creación de ejemplo.

Requisitos previos:

v El archivo de código fuente que contenga una o más implantaciones de rutinas

C o C++ de SQL incorporado.

v El nombre de la base de datos dentro de la instancia de DB2 actual en la que se

van a crear las rutinas.

v Las opciones de compilación y enlace específicas del sistema operativo

necesarias para crear rutinas C y C++. Consulte los temas a los que se hace

referencia en los enlaces relacionados al final de este tema.

Procedimiento:

Para crear un archivo de código fuente que contenga una o más implementaciones

de código de rutina, siga los pasos siguientes. A continuación se describe un

ejemplo que muestra cada uno de los pasos:


2. Navegue hasta el directorio que contiene el archivo de código fuente.

3. Establezca una conexión con la base de datos en la que se van a crear las

rutinas.

4. Precompile el archivo de código fuente.

5. Enlace el paquete que se ha generado con la base de datos.

6. Compile el archivo de código fuente.

7. Enlace el archivo de código fuente para generar una biblioteca compartida. Para

ello hay que utilizar algunas opciones de compilación y enlace específicas de

DB2 correspondientes a compilador que se utiliza.

8. Copie la biblioteca compartida en el directorio de función de DB2 en el

servidor de bases de datos.

9. Si no es la primera vez que se crea el archivo de código fuente que contiene las

implementaciones de rutinas, detenga y vuelva a iniciar la base de datos para

asegurarse de que DB2 utiliza la nueva versión de la biblioteca compartida.

Puede hacerlo emitiendo el mandato db2stop seguido del mandato db2start.


Cuando haya creado y desplegado satisfactoriamente la biblioteca de rutinas, debe

completar los pasos asociados a la tarea de crear rutinas C y C++. La creación de

rutinas C y C++ incluye un paso para ejecutar la sentencia CREATE para cada

rutina implementada en el archivo de código fuente. Este paso también de debe

completar para poder invocar las rutinas.

Ejemplo:

El siguiente ejemplo muestra la recreación de un archivo de código fuente C++ de

SQL incorporado denominado myfile.sqC que contiene implementaciones de

rutinas. Las rutinas se crean en un sistema operativo AIX utilizando el compilador

IBM VisualAge C++ soportado por omisión para generar una biblioteca de rutinas

de 32 bits.


2. Navegue hasta el directorio que contiene el archivo de código fuente.

3. Establezca una conexión con la base de datos en la que se van a crear las

rutinas.

db2 connect to <nombre-basedatos>

4. Precompile el archivo de código fuente con el mandato PREPARE.

db2 prep myfile.sqC bindfile

El precompilador generará salida que indicará si la precompilación se ha

realizado satisfactoriamente o si se ha producido algún error. Este paso genera

un bindfile denominado myfile.bnd que se puede utilizar para generar un

paquete en el siguiente paso.

5. Enlace el paquete generado con la base de datos mediante el mandato BIND.

db2 bind myfile.bnd

El programa de utilidad bind generará salida que indicará si la vinculación se

ha realizado satisfactoriamente o si se ha producido algún error.

6. Compile el archivo de código fuente mediante las opciones recomendadas de

compilación y enlace:

xlC_r -qstaticinline -I$HOME/sqllib/include -c $myfile.C

El compilador generará salida si se produce algún error. Este paso genera un

archivo de exportación denominado myfile.exp.

7. Enlace el archivo de código fuente para generar una biblioteca compartida.

xlC_r -qmkshrobj -o $1 $1.o -L$ HOME/sqllib/include/lib32 -lDB2

El enlazador generará salida si se produce algún error. Este paso genera un

archivo de biblioteca compartida denominado myfile.

8. Copie la biblioteca compartida en el directorio de función de DB2 en el

servidor de bases de datos.

rm -f ~HOME/sqllib/function/myfile

cp myfile $HOME/sqllib/function/myfile

Este paso asegura que la biblioteca de la rutina está en el directorio por

omisión en el que DB2 busca bibliotecas de rutinas. Consulte el tema sobre la

creación de rutinas C y C++ para obtener más información sobre el despliegue

de bibliotecas de rutinas.

9. Detenga y vuelva a iniciar la base de datos puesto que se trata de una

recreación de un archivo de código fuente de rutina anteriormente creado.


db2stop

db2start

La creación de rutinas C y C++ suele resultar más sencilla si se utilizan los scripts

de creación de ejemplo específicos del sistema operativo, que también se pueden

utilizar como referencia para ver cómo crear rutinas desde la línea de mandatos.



página 210




215





página 391


la página 392


página 384


página 395





Opciones de compilación y enlace para rutinas C y C++

Opciones de compilación y enlace para rutinas C de AIX: La tabla siguiente

muestra las opciones de compilación y enlace que DB2 recomienda para crear

rutinas en C (procedimientos almacenados y funciones definidas por el usuario)

con el compilador C de IBM para AIX, tal como muestra el script de creación

bldrtn.


Opciones de compilación y enlace para bldrtn:


xlc_r Utilizar la versión de varias hebras del compilador C de IBM, que es necesaria

porque las rutinas se pueden ejecutar en el mismo proceso que otras rutinas

(THREADSAFE) o en el propio motor (NOT FENCED).

$EXTRA_CFLAG



-I$DB2PATH/include





Opciones de enlace:

xlc_r Indica la utilización de la versión de varias hebras del compilador como interfaz

del editor de enlaces.

$EXTRA_CFLAG



-qmkshrobj

Hace que se cree la biblioteca compartida.

-o $1 Especifica el nombre del archivo de salida.

$1.o Especifica el archivo objeto.


-L$DB2PATH/$LIB




-bE:$1.exp

Especifica un archivo de exportación. El archivo de exportación contiene una lista

de las rutinas.






v “Opciones de compilación y enlace de aplicaciones de API de DB2 y de SQL

incorporado de C de AIX” en la página 234


v “bldrtn -- Builds AIX C routines (stored procedures and UDFs) (C)”

Opciones de compilación y enlace para rutinas C++ de AIX: La tabla siguiente


rutinas en C++ (procedimientos almacenados y funciones definidas por el usuario)

con el compilador XL C/C++ de IBM para AIX, tal como muestra el script de

creación bldrtn.




xlC_r Utilizar la versión de varias hebras del compilador IBM XL C/C++, que es

necesaria porque las rutinas se pueden ejecutar en el mismo proceso que otras

rutinas (THREADSAFE) o en el propio motor (NOT FENCED).

$EXTRA_CFLAG



-I$DB2PATH/include





Opciones de enlace:

xlC_r Indica la utilización de la versión de varias hebras del compilador como interfaz

del editor de enlaces.

$EXTRA_CFLAG



-qmkshrobj

Hace que se cree una biblioteca compartida.

-o $1 Especifica la salida como archivo de biblioteca compartida.


-L$DB2PATH/$LIB





-bE:$1.exp


de las rutinas.










v “Opciones de compilación y enlace de aplicaciones de la API de administración

de DB2 y de SQL incorporado en C++ de AIX” en la página 235


v “bldrtn -- Builds AIX C++ routines (stored procedures and UDFs) (C++)”


Opciones de compilación y enlace para rutinas C de HP-UX: La tabla siguiente



con el compilador C de HP-UX, tal como muestra el script de creación bldrtn.




$EXTRA_CFLAG








+DA2.0W


+DA2.0N

Se debe utilizar para generar código de 32 bits para HP-UX en PA-RISC.+u1 Permitir el acceso a datos no alineados. Sólo si la aplicación utiliza datos no

alineados.

+z Generar código independiente de la posición.

-Ae Habilita la modalidad ampliada ANSI de HP.

-I$DB2PATH/include


-I$DB2PATH/include.

-D_POSIX_C_SOURCE=199506L

Opción de la biblioteca de hebras de POSIX que asegura que esté definido

_REENTRANT, opción necesaria porque las rutinas se pueden ejecutar en el

mismo proceso que otras rutinas (THREADSAFE) o en el propio motor (NOT

FENCED).



Opciones de enlace:

ld Indica la utilización del enlazador para la edición de enlaces.

-b Crear una biblioteca compartida en lugar de un ejecutable normal.



$EXTRA_LFLAG


contiene el valor ″+b$HOME/sqllib/lib32″, y para 64 bits: ″+b$HOME/sqllib/lib64″.

Si no se establece, no contiene ningún valor.

-L$DB2PATH/$LIB




-lpthread

Establece un enlace con la biblioteca de hebras de POSIX.







v “bldrtn -- Builds HP-UX C routines (stored procedures and UDFs) (C)”

Opciones de compilación y enlace para rutinas C++ de HP-UX: La tabla

siguiente muestra las opciones de compilación y enlace que DB2 recomienda para

crear rutinas en C++ (procedimientos almacenados y funciones definidas por el

usuario) con el compilador HP-UX C++, tal como muestra el script de creación

bldrtn.



aCC Indica el compilador aC++ de HP.

$EXTRA_CFLAG








+DA2.0W


+DA2.0N

Se debe utilizar para generar código de 32 bits para HP-UX en PA-RISC.+u1 Permite el acceso a datos no alineados.

+z Generar código independiente de la posición.

-ext Permite el uso de diversas extensiones de C++, tales como el soporte para ″long

long″.

-mt Permite el soporte de hebras para el compilador aC++ de HP, que es necesario

porque las rutinas se pueden ejecutaren el mismo proceso que otras rutinas


-I$DB2PATH/include


$DB2PATH/include




Opciones de enlace:

aCC Hace que el compilador aC++ de HP se utilice como interfaz del editor de enlaces.

$EXTRA_CFLAG








+DA2.0W


+DA2.0N

Se debe utilizar para generar código de 32 bits para HP-UX en PA-RISC.-mt Permite el soporte de hebras para el compilador aC++ de HP, que es necesario

porque las rutinas se pueden ejecutaren el mismo proceso que otras rutinas


-b Crear una biblioteca compartida en lugar de un ejecutable normal.



$EXTRA_LFLAG


contiene el valor -Wl,+b$HOME/sqllib/lib32, y para 64 bits contiene

-Wl,+b$HOME/sqllib/lib64. Si no se establece, no contiene ningún valor.

-L$DB2PATH/$LIB


DB2. Para 32 bits: ″$HOME/sqllib/lib32″; para 64 bits: ″$HOME/sqllib/lib64″.









v “bldrtn -- Builds HP-UX C++ routines (stored procedures and UDFs) (C++)”

Opciones de compilación y enlace para rutinas C de Linux: La tabla siguiente



con el compilador C de Linux, tal como muestra el script de creación bldrtn.




$CC El compilador gcc o xlc_r.

$EXTRA_C_FLAGS





bits; o


-I$DB2PATH/include




enlaces.

-D_REENTRANT

Define la opción _REENTRANT, que es necesaria pues las rutinas se pueden

ejecutar en el mismo proceso que otras rutinas (THREADSAFE) o en el propio

motor (NOT FENCED).

Opciones de enlace:

$CC El compilador gcc o xlc_r; hace que el compilador se utilice como interfaz del

editor de enlaces.

$LINK_FLAGS

Contiene el valor ″$EXTRA_C_FLAGS $SHARED_LIB_FLAG″

$EXTRA_C_FLAGS





bits; o


$SHARED_LIB_FLAG

Contiene -shared para el compilador gcc o -qmkshrobj para el compilador xlc_r.



$EXTRA_LFLAG


Para 32 bits contiene el valor ″-Wl,-rpath,$DB2PATH/lib32″. Para 64 bits contiene

el valor ″-Wl,-rpath,$DB2PATH/lib64″.

-L$DB2PATH/$LIB



$HOME/sqllib/lib64.


-lpthread








v “bldrtn -- Builds Linux C routines (stored procedures or UDFs) (C)”

Opciones de compilación y enlace para rutinas C++ de Linux: La tabla siguiente


rutinas en C++ (procedimientos almacenados y funciones definidas por el usuario)

con el compilador C++ de Linux, tal como muestra el script de creación bldrtn.



g++ Indica el compilador C++ de GNU/Linux.

$EXTRA_C_FLAGS





bits; o


-fpic Genera código independiente de la posición.

-I$DB2PATH/include




enlaces.

-D_REENTRANT

Define la opción _REENTRANT, que es necesaria pues las rutinas se pueden


motor (NOT FENCED).


Opciones de enlace:

g++ Hace que el compilador se utilice como interfaz del editor de enlaces.

$EXTRA_C_FLAGS





bits; o


-shared

Genera una biblioteca compartida.



$EXTRA_LFLAG


Para 32 bits contiene el valor ″-Wl,-rpath,$DB2PATH/lib32″. Para 64 bits contiene

el valor ″-Wl,-rpath,$DB2PATH/lib64″.

-L$DB2PATH/$LIB



$HOME/sqllib/lib64.


-lpthread






v “bldrtn -- Builds Linux C++ routines (stored procedures and UDFs) (C++)”

Opciones de compilación y enlace para rutinas C de Solaris: La tabla siguiente



con el compilador C de Forte, tal como muestra el script de creación bldrtn.





-xarch=$CFLAG_ARCH




-mt Permite el soporte de varias hebras, que es necesario pues las rutinas se pueden


motor (NOT FENCED).

-DUSE_UI_THREADS

Permite el uso de las API de hebras ″UNIX International″ de Sun.

-Kpic Genera código independiente de la posición para bibliotecas compartidas.

-I$DB2PATH/include




Opciones de enlace:


-xarch=$CFLAG_ARCH




-mt Esta opción es necesaria porque la biblioteca de DB2 se enlaza con -mt.

-G Genera una biblioteca compartida.



-L$DB2PATH/$LIB



$HOME/sqllib/lib64.

$EXTRA_LFLAG










v “bldrtn -- Builds Solaris C routines (stored procedures or UDFs) (C)”

Opciones de compilación y enlace para rutinas C++ de Solaris: La tabla

siguiente muestra las opciones de compilación y enlace que DB2 recomienda para


crear rutinas en C++ (procedimientos almacenados y funciones definidas por el

usuario) con el compilador C++ de Forte, tal como muestra el script de creación

bldrtn.



CC Indica el compilador C++.

-xarch=$CFLAG_ARCH




-mt Permite el soporte de varias hebras, que es necesario pues las rutinas se pueden


motor (NOT FENCED).

-DUSE_UI_THREADS

Permite el uso de las API de hebras ″UNIX International″ de Sun.

-Kpic Genera código independiente de la posición para bibliotecas compartidas.

-I$DB2PATH/include




Opciones de enlace:

CC Hace que el compilador se utilice como interfaz del editor de enlaces.

-xarch=$CFLAG_ARCH




-mt Esta opción es necesaria porque la biblioteca de DB2 se enlaza con -mt.

-G Genera una biblioteca compartida.



-L$DB2PATH/$LIB



$HOME/sqllib/lib64.

$EXTRA_LFLAG









v “bldrtn -- Builds Solaris C++ routines (stored procedures or UDFs) (C++)”


Opciones de compilación y enlace para rutinas C y C++ de Windows: A

continuación se muestran las opciones de compilación y enlace recomendadas para

DB2 para crear rutinas C y C++ (procedimientos almacenados y funciones

definidas por el usuario) en Windows con el compilador Microsoft Visual C++, tal

como se muestra en el archivo de proceso por lotes bldrtn.bat.



%BLDCOMP%

Variable del compilador. El valor por omisión es cl, que indica el compilador

Microsoft Visual C++. Puede tener también el valor icl, que indica el compilador

Intel C++ para aplicaciones de 32 ó 64 bits, o ecl, que indica el compilador Intel

C++ para aplicaciones Itanium de 64 bits.

-Zi Habilitar la información de depuración.

-Od Inhabilitar la optimización.



-W2 Emitir mensajes de aviso, de error, de error grave y de error no recuperable.

-DWIN32

Opción de compilador necesaria para los sistemas operativos Windows.

-MD Enlace utilizando MSVCRT.LIB

Opciones de enlace:

link Indica la utilización del enlazador para la edición de enlaces.

-debug Hace que se incluya información de depuración.

-out:%1.dll

Crear un archivo .DLL.

%1.obj Incluir el archivo objeto.

db2api.lib


-def:%1.def

Archivo de definición de módulos.



v “Creación de rutinas C/C++ en Windows” en la página 367


v “bldrtn.bat -- Builds C++ routines (stored procedures and UDFs) on Windows”

v “bldrtn.bat -- Builds C routines (stored procedures and UDFs) on Windows”

Creación de procedimientos almacenados de SQL incorporado

en C o C++ con archivos de configuración

El archivo de configuración, stp.icc en sqllib/samples/c y sqllib/samples/cpp, le

permite crear procedimientos almacenados de SQL incorporado de DB2 en C y

C++ en AIX.

Procedimiento:


Para utilizar el archivo de configuración a fin de crear la biblioteca compartida de

procedimientos almacenados de SQL incorporado, spserver, a partir del archivo

fuente spserver.sqc, siga estos pasos:

1. Asigne a la variable de entorno STP el nombre del programa, de este modo:


export STP=spserver

v En el shell C:

setenv STP spserver

2. Si su directorio de trabajo contiene un archivo stp.ics, resultante de la creación

de un programa diferente con el archivo stp.icc, suprima el archivo stp.ics


rm stp.ics


stp.ics, no es necesario suprimir el archivo.


vacbld stp.icc


La biblioteca compartida de procedimientos almacenados se copia en el directorio

sqllib/function del servidor.

A continuación, catalogue los procedimientos almacenados de la biblioteca

compartida ejecutando el script spcat en el servidor:

spcat

Este script conecta con la base de datos ″sample″, descataloga mediante spdrop.db2

los procedimientos almacenados que se hubieran catalogado previamente, luego los



A continuación, detenga y rearranque la base de datos para que se reconozca la

nueva biblioteca compartida. Si es necesario, establezca la modalidad de archivo

para la biblioteca compartida a fin de que la instancia de DB2 pueda acceder a la

biblioteca.

Una vez creada la biblioteca compartida de procedimientos almacenados, spserver,

puede crear la aplicación cliente, spclient, la cual llama a los procedimientos

almacenados contenidos en la biblioteca. Puede crear spclient utilizando el

archivo de configuración, emb.icc.

Para invocar los procedimientos almacenados, ejecute la aplicación cliente de

ejemplo, especificando lo siguiente: spclient basedatos IDusuario contraseña

donde

basedatos


podría ser sample, o su alias, u otro nombre.

IDusuario



contraseña

Es una contraseña válida.

La aplicación cliente accede a la biblioteca compartida, spserver, la cual ejecuta

diversas funciones de procedimiento almacenado contenidas en la base de datos

del servidor. Los datos resultantes se devuelven a la aplicación cliente.







Creación de funciones definidas por el usuario en C o C++ con

archivos de configuración (AIX)

El archivo de configuración udf.icc, contenido en sqllib/samples/c y

sqllib/samples/cpp, le permite crear funciones definidas por el usuario en C o

C++ en AIX.

Procedimiento:

Para utilizar el archivo de configuración a fin de crear el programa de función

definida por el usuario udfsrv, a partir del archivo fuente udfsrv.c, siga estos

pasos:

1. Asigne a la variable de entorno UDF el nombre del programa, de este modo:


export UDF=udfsrv

v En el shell C:

setenv UDF udfsrv

2. Si su directorio de trabajo contiene un archivo udf.ics, resultante de la creación

de un programa diferente con el archivo udf.icc, suprima el archivo udf.ics


rm udf.ics


udf.ics, no es necesario suprimir el archivo.


vacbld udf.icc


La biblioteca de UDF se copia en el directorio sqllib/function del servidor.

Si es necesario, establezca la modalidad de archivo para la función definida por el

usuario a fin de que la instancia de DB2 pueda ejecutar la función.

Una vez creado el programa udfsrv, puede crear la aplicación cliente, udfcli, la

cual llama al programa. El programa se proporciona en versiones para CLI de DB2

y para SQL incorporado.


Puede crear el programa udfcli de la CLI de DB2, a partir del archivo fuente

udfcli.c, contenido en sqllib/samples/cli, utilizando el archivo de configuración

cli.icc.

Puede crear el programa udfcli de SQL incorporado, a partir del archivo fuente

udfcli.sqc, contenido en sqllib/samples/c, utilizando el archivo de configuración

emb.icc.

Para invocar la UDF, ejecute la aplicación solicitante de ejemplo entrando el

nombre del ejecutable:

udfcli

La aplicación solicitante llama a la función ScalarUDF de la biblioteca udfsrv.







Reconstrucción de bibliotecas compartidas para rutinas de DB2

DB2 situará en la antememoria, una vez cargadas, las bibliotecas compartidas

utilizadas para procedimientos almacenados y funciones definidas por el usuario.

Si está desarrollando una rutina, puede que desee cargar varias veces la misma

biblioteca, y esta utilización de la antememoria le impedirá obtener la última

versión de una biblioteca compartida. La manera de evitar problemas derivados de

la antememoria depende del tipo de rutina:

1. Rutinas delimitadas, no protegidas por hebras. La palabra clave

KEEPFENCED de configuración del gestor de bases de datos tiene un valor por

omisión de YES. Este valor mantiene vivo el proceso en modalidad delimitada.

Este valor por omisión puede interferir con la recarga de la biblioteca. Es

preferible cambiar el valor de esta palabra clave por NO mientras esté

desarrollando rutinas delimitadas, sin protección por hebras, y luego revertir al

valor YES cuando esté preparado para cargar la versión final de la biblioteca

compartida. Para obtener más información, consulte Actualización del archivo

de configuración del gestor de bases de datos .

2. Rutinas fiables o protegidas por hebras. A excepción de las rutinas de SQL

(incluidos los procedimientos de SQL), la única manera de asegurarse que se

obtenga una versión actualizada de la biblioteca de rutinas de DB2 cuando se

utilice dicha biblioteca para rutinas fiables o protegidas por hebras, consiste en

reciclar la instancia de DB2 entrando db2stop seguido de db2start en la línea de

mandatos. Esto no es necesario para una rutina de SQL puesto que, cuando se

recrea, el compilador utiliza un nuevo nombre de biblioteca exclusivo para

evitar posibles conflictos.

Para las rutinas que no son de SQL, también puede evitar los problemas derivados

de la antememoria creando la nueva versión de la rutina con una biblioteca cuyo

nombre sea distinto (por ejemplo, foo.a pasa a ser foo.1.a) y utilizando después las

sentencias ALTER PROCEDURE o ALTER FUNCTION de SQL con la nueva

biblioteca.



v “Actualización del archivo de configuración del gestor de bases de datos” en





Procedimientos COBOL

Procedimientos COBOL

Los procedimientos COBOL se deben escribir de forma similar a los subprogramas

COBOL.

Manejo de parámetros en un procedimiento COBOL

Cada parámetro que un procedimiento debe aceptar o pasar se debe

declarar en LINKAGE SECTION. Por ejemplo, este fragmento de código

corresponde a un procedimiento que acepta dos parámetros IN (un

CHAR(15) y un INT) y pasa un parámetro OUT (un INT):

LINKAGE SECTION.

01 IN-SPERSON PIC X(15).

01 IN-SQTY PIC S9(9) USAGE COMP-5.

01 OUT-SALESSUM PIC S9(9) USAGE COMP-5.

Asegúrese de que los tipos de datos COBOL que declare estén

correctamente correlacionados con tipos de datos SQL. Para obtener una

lista detallada de las correlaciones de tipos de datos entre SQL y COBOL,

consulte ″Tipos de datos SQL soportados en COBOL″.

Cada parámetro se deberá listar entonces en PROCEDURE DIVISION. El

ejemplo siguiente muestra una PROCEDURE DIVISION que corresponde a

las definiciones de parámetros del ejemplo anterior de LINKAGE

SECTION.

PROCEDURE DIVISION USING IN-SPERSON

IN-SQTY

OUT-SALESSUM.

Cómo salir de un procedimiento COBOL

Para salir correctamente del procedimiento, utilice los mandatos siguientes:

MOVE SQLZ-HOLD-PROC TO RETURN-CODE.

GOBACK.

Con estos mandatos, el procedimiento le devuelve correctamente a la

aplicación cliente. Esto resulta especialmente importante cuando llama al

procedimiento una aplicación cliente COBOL local.

Al crear un procedimiento COBOL, es muy recomendable que utilice el script de

creación escrito para su sistema operativo y compilador. Los scripts de creación

para Micro Focus COBOL se encuentran en el directorio sqllib/samples/cobol_mf.

Los scripts de creación para IBM COBOL se encuentran en el directorio

sqllib/samples/cobol.

A continuación, se muestra un ejemplo de procedimiento COBOL que acepta dos

parámetros de entrada y luego devuelve un parámetro de salida y un conjunto de

resultados:


IDENTIFICATION DIVISION.

PROGRAM-ID. "NEWSALE".

DATA DIVISION.

WORKING-STORAGE SECTION.

01 INSERT-STMT.

05 FILLER PIC X(24) VALUE "INSERT INTO SALES (SALES".

05 FILLER PIC X(24) VALUE "_PERSON,SALES) VALUES (’".

05 SPERSON PIC X(16).

05 FILLER PIC X(2) VALUE "’,".

05 SQTY PIC S9(9).

05 FILLER PIC X(1) VALUE ")".


01 INS-SMT-INF.

05 INS-STMT.

49 INS-LEN PIC S9(4) USAGE COMP.

49 INS-TEXT PIC X(100).

01 SALESSUM PIC S9(9) USAGE COMP-5.


EXEC SQL INCLUDE SQLCA END-EXEC.

LINKAGE SECTION.

01 IN-SPERSON PIC X(15).

01 IN-SQTY PIC S9(9) USAGE COMP-5.

01 OUT-SALESSUM PIC S9(9) USAGE COMP-5.

PROCEDURE DIVISION USING IN-SPERSON

IN-SQTY

OUT-SALESSUM.

MAINLINE.

MOVE 0 TO SQLCODE.

PERFORM INSERT-ROW.

IF SQLCODE IS NOT EQUAL TO 0

GOBACK

END-IF.

PERFORM SELECT-ROWS.

PERFORM GET-SUM.

GOBACK.

INSERT-ROW.

MOVE IN-SPERSON TO SPERSON.

MOVE IN-SQTY TO SQTY.

MOVE INSERT-STMT TO INS-TEXT.

MOVE LENGTH OF INSERT-STMT TO INS-LEN.

EXEC SQL EXECUTE IMMEDIATE :INS-STMT END-EXEC.

GET-SUM.

EXEC SQL

SELECT SUM(SALES) INTO :SALESSUM FROM SALES

END-EXEC.

MOVE SALESSUM TO OUT-SALESSUM.

SELECT-ROWS.

EXEC SQL

DECLARE CUR CURSOR WITH RETURN FOR SELECT * FROM SALES

END-EXEC.

IF SQLCODE = 0

EXEC SQL OPEN CUR END-EXEC

END-IF.

La sentencia CREATE PROCEDURE que corresponde a este procedimiento es la

siguiente:

CREATE PROCEDURE NEWSALE ( IN SALESPERSON CHAR(15),

IN SALESQTY INT,

OUT SALESSUM INT)

RESULT SETS 1

EXTERNAL NAME ’NEWSALE!NEWSALE’


FENCED

LANGUAGE COBOL

PARAMETER STYLE SQL

MODIFIES SQL DATA

La sentencia anterior presupone que la función COBOL se halla en una biblioteca

denominada NEWSALE.

Nota: Al registrar un procedimiento COBOL en los sistemas operativos Windows,

tome la precaución siguiente cuando identifique un cuerpo de

procedimiento almacenado en la cláusula EXTERNAL NAME de la sentencia

CREATE. Si utiliza un ID de vía de acceso absoluto para identificar el

cuerpo del procedimiento, debe añadir la extensión .dll. Por ejemplo:

CREATE PROCEDURE NEWSALE ( IN SALESPERSON CHAR(15),

IN SALESQTY INT,

OUT SALESSUM INT)

RESULT SETS 1

EXTERNAL NAME ’NEWSALE!NEWSALE’

FENCED

LANGUAGE COBOL

PARAMETER STYLE SQL

MODIFIES SQL DATA

EXTERNAL NAME ’d:\mylib\NEWSALE.dll’












v “Sentencia CREATE PROCEDURE (Externo)” en Consulta de SQL, Volumen 2



390

Soporte para el desarrollo de procedimientos externos en

COBOL

Para desarrollar procedimientos externos en COBOL debe utilizar el software de

desarrollo COBOL soportado.

Todo el software de desarrollo soportado para desarrollar aplicaciones de bases de

datos en COBOL, se puede utilizar también para el desarrollo de procedimientos

externos en COBOL.


v “Procedimientos COBOL” en la página 388





v “Soporte para el desarrollo de aplicaciones de bases de datos en COBOL” en


Creación de rutinas COBOL

Opciones de compilación y enlace para rutinas COBOL

Opciones de compilación y enlace para rutinas IBM COBOL de AIX: A

continuación se muestran las opciones de compilación y enlace que se recomiendan

para DB2 para crear rutinas COBOL (procedimientos almacenados) con el

compilador IBM COBOL para AIX en AIX, tal como se muestra en el script de

creación bldrtn.



cob2 El compilador IBM COBOL para AIX.

-qpgmname$mixed$






-I$DB2PATH/include/cobol_a


$HOME/sqllib/include/cobol_a.

Opciones de enlace:

cob2 Indica la utilización del compilador para realizar la edición de enlaces.


$1.o Especifica el archivo objeto del procedimiento almacenado.

checkerr.o



-bnoentry

Indica que no se especifique el punto de entrada por omisión de la biblioteca

compartida.

-bE:$1.exp


de los procedimientos almacenados.

-L$DB2PATH/$LIB



-ldb2 Enlazar con la biblioteca del gestor de bases de datos.





v “Configuración del compilador IBM COBOL en AIX” en la página 256



página 259


50


v “bldrtn -- Builds AIX COBOL routines (stored procedures)”

Opciones de compilación y enlace para rutinas Micro Focus COBOL de AIX: A

continuación se muestran las opciones de compilación y enlace que se recomiendan

para DB2 para crear rutinas COBOL (procedimientos almacenados) con el

compilador Micro Focus COBOL en AIX, tal como se muestra en el script de

creación bldrtn. Tenga en cuenta que los archivos de inclusión de DB2 MicroFocus

COBOL se localizan configurando la variable de entorno COBCPY, de modo que

no se necesita el distintivo -I en el paso de compilación. Consulte el script bldapp

para ver un ejemplo.



cob El compilador MicroFocus COBOL.



$EXTRA_COBOL_FLAG="-C MFSYNC"

Habilita el soporte de 64 bits.

-x Compila y crea un módulo objeto cuando se utiliza con la opción -c.

Opciones de enlace:


-x Hace que se cree una biblioteca compartida.



-L$DB2PATH/$LIB




-ldb2gmf






v “Configuración del compilador Micro Focus COBOL en AIX” en la página 257






v “bldrtn -- Builds AIX Micro Focus COBOL routines (stored procedures)”

Opciones de compilación y enlace para rutinas Micro Focus COBOL de HP-UX:


recomienda para crear rutinas COBOL (procedimientos almacenados) con el

compilador Micro Focus COBOL en HP-UX, tal como muestra el script de creación

bldrtn.



cob Indica el compilador COBOL.

$EXTRA_COBOL_FLAG

Contiene ″-C MFSYNC″ si la plataforma HP-UX es IA64 y el soporte de 64 bits

está habilitado.

Opciones de enlace:

-y Especifica que la salida deseada es una biblioteca compartida.


-L$DB2PATH/$LIB


DB2.

-ldb2 Enlazar con la biblioteca compartida de DB2.

-ldb2gmf






v “Configuración del compilador Micro Focus COBOL en HP-UX” en la página

258


v “bldrtn -- Builds HP-UX Micro Focus COBOL routines (stored procedures)”

Opciones de compilación y enlace para rutinas Micro Focus COBOL de Solaris:


recomienda para crear rutinas COBOL (procedimientos almacenados) con el

compilador Micro Focus COBOL en Solaris, tal como muestra el script de creación

bldrtn.



cob Indica el compilador COBOL.


$EXTRA_COBOL_FLAG

Para soporte de 64 bits, contiene el valor ″-C MFSYNC″; de lo contrario, no



Opciones de enlace:


-y Crea una biblioteca compartida autónoma auto-contenida.



-L$DB2PATH/$LIB




-ldb2gmf






v “Configuración del compilador Micro Focus COBOL en Solaris” en la página 258


v “bldrtn -- Builds Solaris Micro Focus COBOL routines (stored procedures)”

Opciones de compilación y enlace para rutinas Micro Focus COBOL de Linux:


recomiendan para DB2 para crear rutinas COBOL (procedimientos almacenados)

con el compilador Micro Focus COBOL en Linux, tal como se muestra en el script

de creación bldrtn.


Opciones de compilación y enlace:

cob Indica el compilador COBOL

$EXTRA_COBOL_FLAG

Para el soporte de 64 bits, contiene el valor ″-C MFSYNC″; de lo contrario, no


-y Especifica compilar para objetos callable compartidos independientes


$1.cbl Especifica el archivo fuente

-L$DB2PATH/$LIB


DB2.


-ldb2gmf






v “Configuración del compilador Micro Focus COBOL en Linux” en la página 255



v “bldrtn -- Builds Linux Micro Focus COBOL routines (stored procedures)”


programs (C)”

Opciones de compilación y enlace para rutinas IBM COBOL de Windows: A

continuación se muestran las opciones de compilación y enlace recomendadas para

DB2 para crear rutinas COBOL (procedimientos almacenados y funciones definidas

por el usuario) en Windows con el compilador IBM VisualAge COBOL, tal como se

muestra en el archivo de proceso por lotes bldrtn.bat.



cob2 El compilador IBM VisualAge COBOL.

-qpgmname(mixed)



-c Hace que se efectúe solamente la compilación, no la edición de enlaces. El archivo

de proceso por lotes tiene pasos separados para la compilación y la edición de

enlaces.


-Ivía Especifica la ubicación de los archivos de inclusión de DB2. Por ejemplo:

-I"%DB2PATH%\include\cobol_a".

%EXTRA_COMPFLAG%

Si "set IBMCOB_PRECOMP=true" no posee comentarios, el precompilador IBM se

utilizará para precompilar el SQL incorporado. Se invocará con una de las

siguientes formulaciones, en función de los parámetros de entrada:

-q"SQL(’database sample CALL_RESOLUTION DEFERRED’)"

precompilar utilizando la base de datos de ejemplo por omisión, y diferir

la resolución de la llamada.

-q"SQL(’database %2 CALL_RESOLUTION DEFERRED’)"

precompilar utilizando una base de datos especificada por el usuario, y

diferir la resolución de la llamada.

Opciones de enlace:

ilink Utilizar el enlazador IBM VisualAge COBOL.

/free Formato libre.

/nol Sin logotipo.

/dll Crear la DLL con el nombre del programa fuente.

db2api.lib


%1.exp Incluir el archivo de exportación.

%1.obj Incluir el archivo objeto del programa.

iwzrwin3.obj

Incluir el archivo de objeto proporcionado por IBM VisualAge COBOL.




v “Configuración del compilador IBM COBOL en Windows” en la página 253


v “bldrtn.bat -- Builds Windows VisualAge COBOL routines (stored procedures)”


Opciones de compilación y enlace para rutinas Micro Focus COBOL de

Windows: La tabla siguiente muestra las opciones de compilación y enlace que

DB2 recomienda para crear rutinas en COBOL (procedimientos almacenados y

funciones definidas por el usuario) cuando se utiliza Windows y el compilador

Micro Focus COBOL, tal como muestra el archivo de proceso por lotes bldrtn.bat.



cobol Indica el compilador Micro Focus COBOL.

/case Impide que los símbolos externos se conviertan en mayúsculas.

Opciones de enlace:

cbllink

Utilizar el enlazador Micro Focus COBOL para la edición de enlaces.

/d Crear un archivo .dll.

db2api.lib

Enlazar con la biblioteca DB2 de la API.




v “Configuración del compilador Micro Focus COBOL en Windows” en la página

254


v “bldrtn.bat -- Builds Windows Micro Focus Cobol routines (stored procedures)”

Creación de rutinas IBM COBOL en AIX

DB2 proporciona scripts de creación para compilar y enlazar programas COBOL de

SQL incorporado y de la API de DB2. Estos scripts residen en el directorio

sqllib/samples/cobol, junto con programas de ejemplo que se pueden crear a


El bldrtn, que reside en sqllib/samples/cobol, contiene los mandatos para crear

rutinas (procedimientos almacenados). El script compila las rutinas y crea una

biblioteca compartida que puede ser llamada por una aplicación cliente.

El primer parámetro, $1, especifica el nombre del archivo fuente. El segundo


Debido a que la biblioteca compartida se debe crear en la misma instancia donde

reside la base de datos, no hay parámetros para el ID de usuario ni la contraseña.

Sólo es obligatorio el primer parámetro, el nombre del archivo fuente. El script

utiliza el nombre del archivo fuente, $1, como nombre de la biblioteca compartida.

El nombre de la base de datos es opcional. Si no se proporciona un nombre de

base de datos, el programa utiliza la base de datos por omisión sample.

Procedimiento:

Si conecta con la base de datos ″sample″, especifique lo siguiente para crear el

programa de ejemplo outsrv a partir del archivo fuente outsrv.sqb:


bldrtn outsrv


datos:

bldrtn outsrv basedatos

El archivo de script copia la biblioteca compartida en el directorio sqllib/function

del servidor.

Una vez creada la biblioteca compartida de la rutina, outsrv, puede crear la

aplicación cliente, outcli, la cual llama a la rutina contenida en la biblioteca. Puede

crear outcli utilizando el archivo de script bldapp.

Para invocar la rutina, ejecute la aplicación cliente de ejemplo, especificando lo

siguiente:

outcli basedatos IDusuario contraseña

donde

basedatos


podría ser sample, o su alias remoto, u otro nombre.

IDusuario


contraseña


La aplicación cliente accede a la biblioteca compartida, outsrv, la cual ejecuta la

rutina del mismo nombre contenida en la base de datos del servidor, y devuelve

los datos resultantes a la aplicación cliente.








página 391



v “bldrtn -- Builds AIX COBOL routines (stored procedures)”

v “embprep -- To prep and bind a COBOL embedded SQL sample on AIX”

v “outcli.sqb -- Call stored procedures using the SQLDA structure (IBM COBOL)”

v “outsrv.sqb -- Demonstrates stored procedures using the SQLDA structure (IBM

COBOL)”


Creación de rutinas Micro Focus COBOL de UNIX

DB2 proporciona scripts de creación para compilar y enlazar programas Micro

Focus COBOL de SQL incorporado y de la API de DB2. Estos scripts residen en el

directorio sqllib/samples/cobol_mf, junto con programas de ejemplo que se


El script bldrtn contiene los mandatos para crear rutinas (procedimientos

almacenados). El script compila el archivo fuente de la rutina y crea una biblioteca

compartida que puede ser llamada por una aplicación cliente.

El primer parámetro, $1, especifica el nombre del archivo fuente. El script utiliza el

nombre del archivo fuente como nombre de la biblioteca compartida. El segundo


Debido a que la biblioteca compartida se debe crear en la misma instancia donde

reside la base de datos, no hay parámetros para el ID de usuario ni la contraseña.




Valores:

Antes de crear las rutinas de Micro Focus COBOL, debe ejecutar estos mandatos:

db2stop

db2set DB2LIBPATH=$LD_LIBRARY_PATH

db2set DB2ENVLIST="COBDIR LD_LIBRARY_PATH"

db2set

db2start

Asegúrese de que db2stop detiene la base de datos. El último mandato db2set se

emite para comprobar los valores: compruebe que DB2LIBPATH y DB2ENVLIST estén

definidos correctamente.

Procedimiento:



bldrtn outsrv


datos:


El archivo de script copia la biblioteca compartida en el directorio sqllib/function

del servidor.

Una vez creado el procedimiento almacenado outsrv, puede crear la aplicación

cliente outcli que llama al procedimiento almacenado. Puede crear outcli

utilizando el archivo de script bldapp.

Para invocar el procedimiento almacenado, ejecute la aplicación cliente de ejemplo,

especificando lo siguiente:


donde


basedatos



IDusuario


contraseña


La aplicación cliente accede a la biblioteca compartida, outsrv, la cual ejecuta la

función de procedimiento almacenado del mismo nombre contenida la base de

datos el servidor. A continuación los datos resultantes se devuelven a la aplicación

cliente.





la página 392

v “Opciones de compilación y enlace para rutinas Micro Focus COBOL de HP-UX”

en la página 393

v “Opciones de compilación y enlace para rutinas Micro Focus COBOL de Linux”

en la página 394

v “Opciones de compilación y enlace para rutinas Micro Focus COBOL de Solaris”

en la página 393


v “bldrtn -- Builds AIX Micro Focus COBOL routines (stored procedures)”

v “bldrtn -- Builds HP-UX Micro Focus COBOL routines (stored procedures)”

v “bldrtn -- Builds Linux Micro Focus COBOL routines (stored procedures)”

v “bldrtn -- Builds Solaris Micro Focus COBOL routines (stored procedures)”

v “outcli.sqb -- Call stored procedures using the SQLDA structure (MF COBOL)”

v “outsrv.sqb -- Demonstrates stored procedures using the SQLDA structure (MF

COBOL)”


programs (C)”

Creación de rutinas IBM COBOL en Windows

DB2 proporciona archivos de creación para compilar y enlazar programas de la

API de DB2 y de SQL incorporado en IBM COBOL. Estos archivos residen en el

directorio sqllib\samples\cobol, junto con programas de ejemplo que se pueden

crear a partir de esos archivos.

DB2 da soporte a dos precompiladores para crear aplicaciones IBM COBOL en

Windows, el precompilador de DB2 y el precompilador de IBM COBOL. El valor

por omisión es el precompilador de DB2. El precompilador de IBM COBOL se

puede seleccionar descomentando la línea apropiada del archivo de proceso por

lotes que se esté utilizando. La precompilación con IBM COBOL la realiza el

propio compilador, utilizando opciones de precompilación específicas.



rutinas (procedimientos almacenados) de SQL incorporado. El archivo de proceso

por lotes compila las rutinas y crea una DLL en el servidor. Utiliza dos parámetros

como entrada, que están representados dentro del archivo de proceso por lotes por

las variables %1 y %2.


proceso por lotes utiliza el nombre del archivo fuente, %1, como nombre de la DLL.

El segundo parámetro, %2, especifica el nombre de la base de datos a la que desea

conectarse. Debido a que el procedimiento almacenado se debe crear en la misma


ni la contraseña.




Si utiliza el precompilador de DB2 por omisión, bldrtn.bat pasa los parámetros al

archivo de precompilación y vinculación, embprep.bat.

Si se utiliza el precompilador de IBM COBOL, bldrtn.bat copia el archivo fuente

.sqb en un archivo fuente .cbl. El compilador realiza la precompilación sobre el

archivo fuente .cbl con opciones de precompilación específicas.

Procedimiento:



bldrtn outsrv


datos:


El archivo de proceso por lotes copia la DLL en la vía de acceso sqllib\function

del servidor.

Una vez creada la DLL outsrv, puede crear la aplicación cliente outcli, la cual

llama a la rutina contenida en la DLL y que tiene el mismo que la DLL. Puede

crear outcli utilizando el archivo de proceso por lotes bldapp.bat.

Para invocar la rutina outsrv, ejecute la aplicación cliente de ejemplo,



donde

basedatos


podría ser sample, su alias remoto u otro nombre.

IDusuario


contraseña



La aplicación cliente accede a la DLL outsrv, la cual ejecuta la rutina del mismo

nombre contenida en la base de datos del servidor, y devuelve los datos resultantes

a la aplicación cliente.







página 395


v “bldrtn.bat -- Builds Windows VisualAge COBOL routines (stored procedures)”

v “embprep.bat -- To prep and bind a COBOL embedded SQL program on

Windows”

v “outcli.sqb -- Call stored procedures using the SQLDA structure (IBM COBOL)”

v “outsrv.sqb -- Demonstrates stored procedures using the SQLDA structure (IBM

COBOL)”

Creación de rutinas Micro Focus COBOL en Windows

DB2 proporciona archivos de creación para compilar y enlazar programas de la

API de DB2 y de SQL incorporado en Micro Focus COBOL. Estos archivos residen

en el directorio sqllib\samples\cobol_mf, junto con programas de ejemplo que se



rutinas (procedimientos almacenados) de SQL incorporado. El archivo de proceso

por lotes compila las rutinas y crea una DLL en el servidor. El archivo utiliza dos

parámetros como entrada, que están representados dentro del archivo de proceso

por lotes por las variables %1 y %2.


proceso por lotes utiliza el nombre del archivo fuente, %1, como nombre de la DLL.

El segundo parámetro, %2, especifica el nombre de la base de datos a la que desea

conectarse. Debido a que el procedimiento almacenado se debe crear en la misma


ni la contraseña.




Procedimiento:



bldrtn outsrv


datos:



El archivo de script copia la DLL en el directorio sqllib/function del servidor.

Una vez creada la DLL outsrv, puede crear la aplicación cliente outcli, la cual

llama a la rutina contenida en la DLL y que tiene el mismo que la DLL. Puede

crear outcli utilizando el archivo de proceso por lotes bldapp.bat.

Para invocar la rutina outsrv, ejecute la aplicación cliente de ejemplo,



donde

basedatos



IDusuario


contraseña


La aplicación cliente accede a la DLL outsrv, la cual ejecuta la rutina del mismo

nombre contenida en la base de datos del servidor. A continuación los datos

resultantes se devuelven a la aplicación cliente.









v “bldrtn.bat -- Builds Windows Micro Focus Cobol routines (stored procedures)”

v “outcli.sqb -- Call stored procedures using the SQLDA structure (MF COBOL)”

v “outsrv.sqb -- Demonstrates stored procedures using the SQLDA structure (MF

COBOL)”




Parte 3. Apéndices


Apéndice A. Ejemplos de SQL incorporado

Ejemplos de C

Directorio UNIX: sqllib/samples/c. Directorio Windows: sqllib\samples\c.

Extensiones de archivos: .c (sin SQL incorporado); .sqc (SQL incorporado)

Tabla 29. Archivos de programas de ejemplo de C

Tipo de ejemplo Nombre del programa de ejemplo Descripción del programa

Nivel de cliente cli_info.c Cómo obtener y definir información a nivel de cliente.

clisnap.c Cómo capturar una instantánea a nivel de cliente.

clisnapnew.c Cómo obtener una instantánea a nivel de cliente

(utilizando API).

Nivel de instancia inattach.c Cómo conectar/desconectar respecto a una instancia.

inauth.sqc Cómo visualizar autorizaciones a nivel de instancia.

ininfo.c Cómo obtener y definir información a nivel de instancia.

insnap.c Cómo capturar una instantánea a nivel de instancia.

insnapnew.c Cómo obtener una instantánea a nivel de instancia

(utilizando API).

instart.c Cómo detener e iniciar la instancia local actual.


Tabla 29. Archivos de programas de ejemplo de C (continuación)


Nivel de base de

datos

autostore.c Cómo utilizar la función de almacenamiento automático

para una base de datos.

dbauth.sqc Cómo visualizar/otorgar/revocar autorizaciones a nivel

de base de datos.

dbcfg.sqc Cómo configurar parámetros de base de datos y de

gestor de bases de datos.

dbconn.sqc Cómo conectar y desconectar con respecto de una base

de datos.

dbcreate.c Cómo crear y eliminar bases de datos.

dbhistfile.sqc Cómo leer y actualizar una entrada de archivo de

historia de recuperación de base de datos.

dbinfo.c Cómo obtener y definir información a nivel de base de

datos.

dbinline.sqc Cómo utilizar el lenguaje de procedimientos SQL

incorporados.

dbinspec.sqc Cómo verificar la integridad arquitectural con la API de

DB2 db2Inspect.

dblogconn.sqc Cómo leer archivos de registro de base de datos de

forma asíncrona con una conexión de base de datos.

dblognoconn.sqc Cómo leer archivos de registro de base de datos de

forma asíncrona sin ninguna conexión de base de datos.

dbmcon.sqc Cómo conectar y desconectar con respecto a varias bases

de datos.

dbmcon1.h Archivo de cabecera de dbmcon1.sqc.

dbmcon1.sqc Archivo de soporte de dbmcon.sqc.

dbmcon2.h Archivo de cabecera de dbmcon2.sqc.

dbmcon2.sqc Archivo de soporte de dbmcon.sqc.

dbmigrat.c Cómo migrar una base de datos.

dbpkg.sqc Cómo trabajar con paquetes.

dbrec.sqc Cómo utilizar la API db2GetRecommendations.

dbrecov.sqc Cómo recuperar una base de datos.

dbredirect.sqc Cómo realizar una Restauración redirigida de una base

de datos.

dbrestore.sqc Cómo restaurar una base de datos a partir de una copia

de seguridad.

dbrollfwd.sqc Cómo realizar una retrotracción después de una

restauración de una base de datos.

dbsample.sqc Cómo crear la base de datos de ejemplo de forma que

incluya tablas y vistas de Host y AS/400.

dbsnap.c Cómo capturar una instantánea a nivel de base de datos.

dbsnapnew.c Cómo obtener una instantánea a nivel de base de datos

(utilizando API).

dbthrds.sqc Cómo utilizar las API de múltiples contextos en UNIX.

dbthrds.sqc Cómo utilizar las API de múltiples contextos en

Windows.

dbuse.sqc Cómo utilizar objetos de base de datos.

getlogs.sqc Cómo obtener una vista de cliente de entradas de

archivo de anotaciones cronológicas de diagnóstico.

Nivel de espacio

de tabla

tscreate.sqc Cómo crear y eliminar agrupaciones de

almacenamientos intermedios y espacios de tablas.

tsinfo.sqc Cómo obtener información a nivel de espacio de tabla.




Nivel de tabla getmessage.sqc Cómo obtener un mensaje de error en el entorno local

necesario con sustitución de símbolos.

largerid.sqc Cómo ampliar el soporte a RID grandes en

tablas/espacios de tabla nuevos y existentes.

setintegrity.sqc Cómo ejecutar SET INTEGRITY en línea sobre una tabla.

tbast.sqc Cómo utilizar una tabla de etapas para actualizar una

Tabla de resumen automático diferida.

tbcompress.sqc Cómo crear tablas con opciones de compresión de

valores por omisión y nulos.

tbconstr.sqc Cómo trabajar con restricciones de tabla.

tbcreate.sqc Cómo crear, modificar y eliminar tablas.

tbident.sqc Cómo utilizar columnas de identidad.

tbinfo.sqc Cómo obtener y definir información a nivel de tabla.

tbintrig.sqc Cómo utilizar un desencadenante ’INSTEAD OF’ en una

vista.

tbload.sqc Cómo cargar en una base de datos particionada.

tbloadcursor.sqc Cómo cargar datos devueltos desde una sentencia

SELECT en una tabla mediante el método CURSOR o el

método de soporte REMOTEFETCH.

tbmerge.sqc Cómo utilizar la sentencia MERGE.

tbmod.sqc Cómo modificar información de una tabla.

tbmove.sqc Cómo mover datos de tablas.

tbonlineinx.sqc Cómo crear y reorganizar índices en una tabla.

tbpriv.sqc Cómo visualizar/otorgar/revocar privilegios a nivel de

tabla.

tbread.sqc Cómo leer información de una tabla.

tbreorg.sqc Cómo reorganizar una tabla.

tbrowcompress.sqc Cómo ejecutar la compresión de filas sobre una tabla.

tbrunstats.sqc Cómo ejecutar runstats sobre una tabla.

tbsavept.sqc Cómo utilizar puntos de salvar externos.

tbsel.sqc Cómo seleccionar de entre: inserción, actualización,

supresión.

tbselcreate.db2 Cómo crear las tablas para el programa tbsel.

tbseldrop.db2 Cómo eliminar las tablas del programa tbsel.

tbtemp.sqc Cómo utilizar una tabla temporal declarada.

tbtrig.sqc Cómo utilizar un desencadenante en una tabla.

tbumqt.sqc Cómo utilizar tablas de consultas materializadas (tablas

de resumen).

tbunion.sqc Cómo insertar utilizando una vista UNION ALL.

Nivel de tipo de

datos

dtformat.sqc Cómo utilizar extensiones de formato de datos de carga

e importación.

dtlob.sqc Cómo leer y escribir datos de LOB.

dtudt.sqc Cómo crear, utilizar y eliminar tipos diferenciados

definidos por el usuario.

Nivel de función

de DB2

fnuse.sqc Cómo utilizar funciones de SQL.

Apéndice A. Ejemplos de SQL incorporado 407



Nivel de

procedimiento

almacenado

spcat Script del catálogo de procedimientos almacenados para

el programa spserver. Este script llama a spdrop.db2 y

spcreate.db2.

spcreate.db2 Script de CLP para emitir sentencias CREATE

PROCEDURE.

spdrop.db2 Script de CLP para eliminar procedimientos

almacenados del catálogo.

spclient.sqc Programa cliente utilizado para llamar a las rutinas de

servidor declaradas en spserver.sqc.

spserver.sqc Rutinas de procedimiento almacenado creadas y

ejecutadas en el servidor.

Nivel de UDF udfcli.sqc Aplicación cliente que sirve para llamar a la función

definida por el usuario contenida en udfsrv.c, udfsrv.C.

udfsrv.c Función definida por el usuario ScalarUDF invocada por

udfcli.sqc

udfemcli.sqc Aplicación cliente que sirve para llamar a la biblioteca

de funciones definidas por el usuario de SQL

incorporado, udfemsrv.

udfemsrv.sqc Biblioteca de funciones definidas por el usuario de SQL

incorporado invocada por udfemcli.

Otros evm.sqc Cómo crear y analizar supervisores de sucesos de

archivos, conexiones y tablas.

utilrecov.c Programas de utilidad para los archivos de copia de

seguridad, restauración y registro.

utilsnap.c Programas de utilidad para los programas de ejemplo

de supervisión de capturas.






Ejemplos de COBOL

Directorios de UNIX. IBM COBOL: sqllib/samples/cobol; Micro Focus COBOL:

sqllib/samples/cobol_mf.

Directorios de Windows. IBM COBOL: sqllib\samples\cobol; Micro Focus

COBOL: sqllib\samples\cobol_mf.

Nota: Los ejemplos de COBOL no están estructurados según el diseño de niveles

de DB2 utilizado para los ejemplos de C, CLI, C++, C#, Java, Perl, PHP,

Visual Basic ADO y Visual Basic .NET.

Tabla 30. Programas COBOL de ejemplo de la API de DB2 sin SQL incorporado

Programa de

ejemplo API incluida

checkerr.cbl v sqlaintp - Obtener mensaje de error

v sqlogstt - Obtener mensaje de SQLSTATE

client.cbl v sqleqryc - Consultar cliente

v sqlesetc - Definir cliente


Tabla 30. Programas COBOL de ejemplo de la API de DB2 sin SQL

incorporado (continuación)

Programa de


d_dbconf.cbl v sqleatin - Conectar

v sqledtin - Desconectar

v sqlfddb - Obtener valores por omisión de configuración de base de

datos

d_dbmcon.cbl v sqleatin - Conectar


v sqlfdsys - Obtener valores por omisión de configuración de gestor

de bases de datos

db_udcs.cbl v sqleatin - Conectar

v sqlecrea - Crear base de datos

v sqledrpd - Eliminar base de datos

dbcat.cbl v sqlecadb - Catalogar base de datos

v db2DbDirCloseScan - Cerrar exploración de directorio de base de

datos

v db2DbDirGetNextEntry - Obtener entrada siguiente del directorio

de base de datos

v db2DbDirOpenScan - Abrir exploración de directorio de base de

datos

v sqleuncd - Descatalogar base de datos

dbcmt.cbl v sqledcgd - Cambiar comentario de base de datos

v db2DbDirCloseScan - Cerrar exploración de directorio de base de

datos

v db2DbDirGetNextEntry - Obtener entrada siguiente del directorio

de base de datos

v db2DbDirOpenScan - Abrir exploración de directorio de base de

datos

v sqleisig - Instalar gestor de señales

dbconf.cbl v sqleatin - Conectar



v sqlfrdb - Restaurar configuración de base de datos

v sqlfudb - Actualizar configuración de base de datos

v sqlfxdb - Obtener configuración de base de datos

dbinst.cbl v sqleatcp - Conectar y cambiar contraseña

v sqleatin - Conectar


v sqlegins - Obtener instancia

dbmconf.cbl v sqleatin - Conectar


v sqlfrsys - Restaurar configuración de gestor de bases de datos

v sqlfusys - Actualizar configuración de gestor de bases de datos

v sqlfxsys - Obtener configuración de gestor de bases de datos


Tabla 30. Programas COBOL de ejemplo de la API de DB2 sin SQL


Programa de


dbsnap.cbl v sqleatin - Conectar

v sqlmonss - Obtener instantánea

dbstart.cbl v sqlepstart - Iniciar gestor de bases de datos

dbstop.cbl v sqlefrce - Forzar aplicación

v sqlepstp - Detener gestor de bases de datos

dcscat.cbl v sqlegdad - Catalogar bases de datos DCS

v sqlegdcl - Cerrar exploración de directorio DCS

v sqlegdel - Descatalogar base de datos DCS

v sqlegdge - Obtener entrada de directorio DCS para base de datos

v sqlegdgt - Obtener entradas de directorio DCS

v sqlegdsc - Abrir exploración de directorio DCS

ebcdicdb.cbl v sqleatin - Conectar



migrate.cbl v sqlemgdb - Migrar base de datos

monreset.cbl v sqleatin - Conectar

v sqlmrset - Restaurar monitor

monsz.cbl v sqleatin - Conectar

v sqlmonss - Obtener instantánea

v sqlmonsz - Calcular tamaño necesario para almacenamiento

intermedio de salida de sqlmonss()

nodecat.cbl v sqlectnd - Catalogar nodo

v sqlencls - Cerrar exploración de directorio de nodo

v sqlengne - Obtener entrada siguiente del directorio de nodo

v sqlenops - Abrir exploración de directorio de nodo

v sqleuncn - Descatalogar nodo

restart.cbl v sqlerstd - Reiniciar base de datos

setact.cbl v sqlesact - Definir cadena de contabilidad

sws.cbl v sqleatin - Conectar

v sqlmon - Obtener/Actualizar conmutadores de monitor

Tabla 31. Programas COBOL de ejemplo de la API de DB2 con SQL incorporado

Programa de


dbauth.sqb v sqluadau - Obtener autorizaciones

dbstat.sqb v db2Reorg - Reorganizar tabla

v db2Runstats - Ejecutar estadísticas

expsamp.sqb v db2Export - Exportar

v sqluimpr - Importar


Tabla 31. Programas COBOL de ejemplo de la API de DB2 con SQL


Programa de


impexp.sqb v db2Export - Exportar

v sqluimpr - Importar

loadqry.sqb v db2LoadQuery - Cargar consulta

rebind.sqb v sqlarbnd - Volver a vincular

tabscont.sqb v sqlbctcq - Cerrar consulta del contenedor del espacio de tabla

v sqlbftcq - Recuperar consulta del contenedor del espacio de tabla

v sqlbotcq - Abrir consulta del contenedor del espacio de tabla

v sqlbtcq - Consulta del contenedor del espacio de tabla

v sqlefmem - Liberar memoria

tabspace.sqb v sqlbctsq - Cerrar consulta del espacio de tabla

v sqlbftpq - Recuperar consulta del espacio de tabla

v sqlbgtss - Obtener estadísticas del espacio de tabla

v sqlbmtsq - Consulta del espacio de tabla

v sqlbotsq - Abrir consulta del espacio de tabla

v sqlbstpq - Consulta individual del espacio de tabla


tload.sqb v db2Export - Exportar

v sqluload - Cargar

v sqluvqdp - Inmovilizar espacios de tablas para tabla

tspace.sqb v sqlbctcq - Cerrar consulta del contenedor del espacio de tabla

v sqlbctsq - Cerrar consulta del espacio de tabla

v sqlbftcq - Recuperar consulta del contenedor del espacio de tabla

v sqlbftpq - Recuperar consulta del espacio de tabla

v sqlbgtss - Obtener estadísticas del espacio de tabla

v sqlbmtsq - Consulta del espacio de tabla

v sqlbotcq - Abrir consulta del contenedor del espacio de tabla

v sqlbotsq - Abrir consulta del espacio de tabla

v sqlbstpq - Consulta individual del espacio de tabla

v sqlbstsc - Definir contenedores del espacio de tabla

v sqlbtcq - Consulta del contenedor del espacio de tabla


Tabla 32. Programas COBOL de ejemplo con SQL incorporado sin ninguna API de DB2

Nombre del

programa de

ejemplo Descripción del programa

advsql.sqb Muestra el uso de expresiones complejas de SQL, tales como CASE,

CAST, y selecciones completas escalares.

cursor.sqb Muestra el uso de un cursor que utiliza SQL estático.

delet.sqb Muestra el uso de SQL estático para suprimir elementos de una base de

datos.


Tabla 32. Programas COBOL de ejemplo con SQL incorporado sin ninguna API de

DB2 (continuación)

Nombre del

programa de

ejemplo Descripción del programa

dynamic.sqb Muestra el uso de un cursor que utiliza SQL dinámico.

joinsql.sqb Muestra el uso de expresiones de unión complejas de SQL.

lobeval.sqb Muestra el uso de localizadores de LOB y difiere la evaluación de los

datos LOB propiamente dichos.

lobfile.sqb Muestra el uso de los descriptores de archivo de LOB.

lobloc.sqb Muestra el uso de los localizadores de LOB.

openftch.sqb Muestra cómo recuperar, actualizar y suprimir filas utilizando SQL

estático.

static.sqb Muestra el uso de SQL estático para recuperar información.

tabsql.sqb Muestra el uso de expresiones complejas de tabla de SQL.

trigsql.sqb Muestra el uso de desencadenantes y restricciones complejos de SQL.

updat.sqb Muestra el uso de SQL estático para actualizar una base de datos.

varinp.sqb Muestra el uso de datos de entrada variables para llamadas a sentencias

de SQL dinámico incorporadas utilizando marcadores de parámetros.






Ejemplos de REXX

Directorio AIX: sqllib/samples/rexx. Directorio Windows: sqllib\samples\rexx.

Tabla 33. Archivos de programas de ejemplo de REXX.

Nombre del

archivo de

ejemplo

Descripción del archivo

blobfile.cmd Muestra el manejo de los BLOB (Binary Large OBject).

chgisl.cmd Muestra el uso de la API: CHANGE ISOLATION LEVEL.

client.cmd Muestra el uso de las API: SET CLIENT y QUERY CLIENT.

d_dbconf.cmd Muestra el uso de la API: GET DATABASE CONFIGURATION DEFAULTS

d_dbmcon.cmd Muestra el uso de la API: GET DATABASE MANAGER

CONFIGURATION DEFAULTS

db_udcs.cmd Muestra el uso de las API CREATE DATABASE y DROP DATABASE para

simular el comportamiento de una secuencia de clasificación de DB2 para

MVS/ESA CCSID 500 (EBCDIC International).

dbauth.cmd Muestra el uso de la API: GET AUTHORIZATIONS


Tabla 33. Archivos de programas de ejemplo de REXX. (continuación)

Nombre del

archivo de

ejemplo


dbcat.cmd Muestra el uso de las API siguientes:

CATALOG DATABASE

CLOSE DATABASE DIRECTORY SCAN

GET NEXT DATABASE DIRECTORY ENTRY

OPEN DATABASE DIRECTORY SCAN

UNCATALOG DATABASE

dbcmt.cmd Muestra el uso de las API siguientes:

CHANGE DATABASE COMMENT

GET ERROR MESSAGE

INSTALL SIGNAL HANDLER

dbconf.cmd Muestra el uso de las API siguientes:

CREATE DATABASE

DROP DATABASE

GET DATABASE CONFIGURATION

RESET DATABASE CONFIGURATION

UPDATE DATABASE CONFIGURATION

dbinst.cmd Muestra el uso de las API siguientes:

ATTACH TO INSTANCE

DETACH FROM INSTANCE

GET INSTANCE

dbmconf.cmd Muestra el uso de las API siguientes:

GET DATABASE MANAGER CONFIGURATION

RESET DATABASE MANAGER CONFIGURATION

UPDATE DATABASE MANAGER CONFIGURATION

dbstart.cmd Muestra el uso de la API: START DATABASE MANAGER

dbstat.cmd Muestra el uso de las API siguientes:

REORGANIZE TABLE

RUN STATISTICS

dbstop.cmd Muestra el uso de las API siguientes:

FORCE USERS

STOP DATABASE MANAGER

dcscat.cmd Muestra el uso de las API siguientes:

ADD DCS DIRECTORY ENTRY

CLOSE DCS DIRECTORY SCAN

GET DCS DIRECTORY ENTRY FOR DATABASE

GET DCS DIRECTORY ENTRIES

OPEN DCS DIRECTORY SCAN

UNCATALOG DCS DIRECTORY ENTRY

dynamic.cmd Muestra el uso de un cursor que utiliza SQL dinámico

ebcdicdb.cmd Muestra el uso de las API CREATE DATABASE y DROP DATABASE para

simular el comportamiento de una secuencia de clasificación de DB2 para

MVS/ESA CCSID 037 (EBCDIC - inglés americano)

impexp.cmd Muestra el uso de las API: EXPORT e IMPORT.

lobeval.cmd Muestra cómo diferir la evaluación de un LOB dentro de una base de

datos

lobfile.cmd Muestra el uso de los descriptores de archivo de LOB

lobloc.cmd Muestra el uso de los localizadores de LOB

lobval.cmd Muestra el uso de los LOB


Tabla 33. Archivos de programas de ejemplo de REXX. (continuación)

Nombre del

archivo de

ejemplo


migrate.cmd Muestra el uso de la API: MIGRATE DATABASE

nodecat.cmd Muestra el uso de las API siguientes:

CATALOG NODE

CLOSE NODE DIRECTORY SCAN

GET NEXT NODE DIRECTORY ENTRY

OPEN NODE DIRECTORY SCAN

UNCATALOG NODE

quitab.cmd Muestra el uso de la API: QUIESCE TABLESPACES FOR TABLE

rechist.cmd Muestra el uso de las API siguientes:

CLOSE RECOVERY HISTORY FILE SCAN

GET NEXT RECOVERY HISTORY FILE ENTRY

OPEN RECOVER HISTORY FILE SCAN

PRUNE RECOVERY HISTORY FILE ENTRY

UPDATE RECOVERY HISTORY FILE ENTRY

restart.cmd Muestra el uso de la API: RESTART DATABASE

sqlecsrx.cmd Es un ejemplo de secuencia de clasificación

updat.cmd Utiliza SQL dinámico para actualizar una base de datos




v “Creación de aplicaciones Object REXX en Windows” en la página 267


Apéndice B. Información técnica sobre DB2 Database

Visión general de la información técnica de DB2

La información técnica de DB2 está disponible a través de las herramientas y los

métodos siguientes:

v Centro de información de DB2

– Temas

– Ayuda para herramientas de DB2

– Programas de ejemplo

– Guías de aprendizajev Manuales de DB2

– Archivos PDF (descargables)

– Archivos PDF (del CD en PDF de DB2)

– manuales en copia impresav Ayuda de línea de mandatos

– Ayuda de mandatos

– Ayuda de mensajesv Programas de ejemplo

IBM proporciona periódicamente actualizaciones de la documentación. Si accede a

la versión en línea del Centro de información de DB2 en ibm.com, no es necesario

que instale las actualizaciones de la documentación porque IBM mantiene

actualizada esta versión. Si ha instalado el Centro de información de DB2, es

recomendable instalar las actualizaciones de la documentación. Las actualizaciones

de la documentación permiten actualizar la información que instaló desde el CD

del Centro de información de DB2 o que descargó de Passport Advantage a

medida que información nueva pasa a estar disponible.

Nota: Los temas del Centro de información de DB2 se actualizan con más

frecuencia que los manuales en PDF o impresos. Para obtener la información

más actualizada, instale las actualizaciones de la documentación cuando

estén disponibles, o consulte el Centro de información de DB2 en ibm.com.

Puede acceder a información técnica adicional de DB2 como, por ejemplo, notas

técnicas, White papers y Redbooks en línea en el sitio ibm.com. Acceda al sitio de

la biblioteca de software de gestión de información de DB2 en

http://www.ibm.com/software/data/sw-library/.

Comentarios sobre la documentación

Agradecemos los comentarios sobre la documentación de DB2. Si tiene sugerencias

sobre cómo podemos mejorar la documentación de DB2, envíe un correo

electrónico a [email protected]. El personal encargado de la documentación de

DB2 lee todos los comentarios de los usuarios, pero no puede responder

directamente a cada uno. Proporcione ejemplos específicos siempre que sea posible

de manera que podamos comprender mejor sus problemas. Si realiza comentarios

sobre un tema o archivo de ayuda determinado, incluya el título del tema y el

URL.


http://www.ibm.com/software/data/sw-library/

No utilice esta dirección de correo electrónico para contactar con el Servicio al

cliente de DB2. Si tiene un problema técnico de DB2 que no está tratado por la

documentación, consulte al centro local de servicio técnico de IBM para obtener

ayuda.


v “Características del Centro de información de DB2” en Centro de información de

DB2 en línea



v “Invocación de ayuda de mandatos desde el procesador de línea de mandatos”

en Consulta de mandatos

v “Invocación de ayuda de mensajes desde el procesador de línea de mandatos”


v “Actualización del Centro de información de DB2 instalado en el sistema o en

un servidor de intranet” en la página 421


v “Biblioteca técnica de DB2 en formato PDF” en la página 416

Biblioteca técnica de DB2 en formato PDF

Las tablas siguientes describen la biblioteca de DB2 que está disponible en el

Centro de publicaciones de IBM en www.ibm.com/shop/publications/order.

Aunque las tablas identifican los manuales en copia impresa disponibles, puede

que dichos manuales no estén disponibles en su país o región.

La información de estos manuales es fundamental para todos los usuarios de DB2;

esta información le resultará útil tanto si es un programador o un administrador de

bases de datos como si trabaja con DB2 Connect u otros productos de DB2.

Tabla 34. Información técnica de DB2

Nombre Número de documento Copia impresa disponible

Administration Guide:

Implementation

SC10-4221 Sí

Administration Guide: Planning SC10-4223 Sí

Consulta de las API

administrativas

SC11-3192 Sí

Vistas y rutinas administrativas

SQL

SC11-3194 No

Call Level Interface Guide and

Reference, Volume 1

SC10-4224 Sí

Call Level Interface Guide and

Reference, Volume 2

SC10-4225 Sí

Consulta de mandatos SC11-3179 No

Data Movement Utilities Guide

and Reference

SC10-4227 Sí

Data Recovery and High

Availability Guide and Reference

SC10-4228 Sí



Tabla 34. Información técnica de DB2 (continuación)


Desarrollo de aplicaciones

ADO.NET y OLE DB

SC11-3178 Sí

Desarrollo de aplicaciones de SQL

incorporado

SC11-3190 Sí

Desarrollo de SQL y rutinas

externas

SC11-3381 No

Desarrollo de aplicaciones Java SC11-3189 Sí

Desarrollo de aplicaciones Perl y

PHP

SC11-3187 No

Iniciación al desarrollo de

aplicaciones de bases de datos

SC11-3188 Sí

Iniciación a la instalación y

administración de DB2 en Linux

y Windows

GC11-3195 Sí

Consulta de mensajes Volumen 1 SC11-3184 No

Consulta de mensajes Volumen 2 SC11-3198 No

Guía de migración GC11-3196 Sí

Net Search Extender Guía de

administración y del usuario

Nota: El HTML para este

documento no se instala desde

el CD de documentación

HTML.

SH10-9290 Sí

Performance Guide SC10-4222 Sí

Query Patroller Administration

and User’s Guide

GC10-4241 Sí

Guía rápida de iniciación para

clientes DB2

GC11-3182 No


servidores DB2

GC11-3181 Sí

Spatial Extender y Geodetic Data

Management Feature Guía del

usuario y manual de consulta

SC11-3229 Sí

Guía de SQL SC11-3191 Sí

Consulta de SQL, Volumen 1 SC11-3180 Sí

Consulta de SQL, Volumen 2 SC11-3193 Sí

System Monitor Guide and

Reference

SC10-4251 Sí

Troubleshooting Guide GC10-4240 No

Guía de aprendizaje de Visual

Explain

SC11-3357 No

Novedades SC11-3185 Sí

XML Extender Administración y

programación

SC11-3230-00 Sí

XML Guide SC10-4254 Sí

XQuery Reference SC18-9796 Sí

Apéndice B. Información técnica sobre DB2 Database 417

Tabla 35. Información técnica específica de DB2 Connect


DB2 Connect Guía del usuario SC11-3197 Sí

Quick Beginnings for DB2

Connect Personal Edition

GC10-4244 Sí


servidores DB2 Connect

GC11-3183 Sí

Tabla 36. Información técnica de integración de la información de WebSphere


WebSphere Information

Integration: Administration Guide

for Federated Systems

SC19-1020 Sí


Integration: ASNCLP Program

Reference for Replication and

Event Publishing

SC19-1018 Sí


Integration: Configuration Guide

for Federated Data Sources

SC19-1034 No


Integration: SQL Replication

Guide and Reference

SC19-1030 Sí

Nota: Las Notas de release de DB2 proporcionan información adicional específica

para el release del producto y el nivel de fixpack. Para obtener más

información, consulte los enlaces relacionados.


v “Visión general de la información técnica de DB2” en la página 415

v “Acerca de las notas del release” en Notas del release


v “Pedido de manuales de DB2 en copia impresa” en la página 418

Pedido de manuales de DB2 en copia impresa

Si necesita manuales de DB2 en copia impresa, puede comprarlos en línea en

varios, pero no en todos los países o regiones. Siempre puede hacer pedidos de

manuales de DB2 en copia impresa a través del representante local de IBM.

Recuerde que algunos manuales en copia software del CD Documentación en PDF

de DB2 no están disponibles en copia impresa. Por ejemplo, ningún volumen de

Consulta de mensajes de DB2 está disponible como manual impreso.

Las versiones impresas de muchos de los manuales de DB2 disponibles en el CD

de la Documentación PDF de DB2 se pueden solicitar a IBM por una cantidad.

Dependiendo desde dónde realice el pedido, podrá solicitar manuales en línea,

desde el Centro de publicaciones de IBM. Si la realización de pedidos en línea no

está disponible en su país o región, siempre puede hacer pedidos de manuales de


DB2 en copia impresa al representante local de IBM. Tenga en cuenta que no todos

los manuales del CD de la Documentación PDF de DB2 están disponibles en copia

impresa.

Nota: La documentación más actualizada y completa de DB2 se mantiene en el

Centro de información de DB2 en el sitio http://publib.boulder.ibm.com/infocenter/db2help/.

Procedimiento:

Para hacer pedidos de manuales de DB2 en copia impresa:

v Para averiguar si puede hacer pedidos de manuales de DB2 en copia impresa en

línea en su país o región, consulte el Centro de publicaciones de IBM en el sitio

http://www.ibm.com/shop/publications/order. Debe seleccionar un país, región

o idioma para poder acceder a la información sobre pedidos de publicaciones y,

a continuación, seguir las instrucciones sobre pedidos para su localidad.

v Para hacer pedidos de manuales de DB2 en copia impresa a través del

representante local de IBM:

– Localice la información de contacto de su representante local desde uno de

los siguientes sitios Web:

- El directorio de IBM de contactos en todo el mundo en el sitio

www.ibm.com/planetwide

- El sitio Web de publicaciones de IBM en el sitio http://www.ibm.com/shop/publications/order. Tendrá que seleccionar su país, región o idioma

para acceder a la página de presentación de las publicaciones apropiadas

para su localidad. Desde esta página, siga el enlace ″Acerca de este sitio″.– Cuando llame, indique que desea hacer un pedido de una publicación de

DB2.

– Proporciónele al representante los títulos y los números de documento de los

manuales que desee solicitar .




v “Biblioteca técnica de DB2 en formato PDF” en la página 416

Visualización de la ayuda para estados de SQL desde el procesador

de línea de mandatos

DB2 devuelve un valor de SQLSTATE para las condiciones que pueden ser el

resultado de una sentencia de SQL. La ayuda de SQLSTATE explica los

significados de los estados de SQL y los códigos de las clases de estados de SQL.

Procedimiento:

Para invocar la ayuda para estados de SQL, abra el procesador de línea de

mandatos y entre:

? sqlstate o ? código de clase

donde sqlstate representa un estado de SQL válido de cinco dígitos y código de clase

representa los dos primeros dígitos del estado de SQL.


http://publib.boulder.ibm.com/infocenter/db2help/






Por ejemplo, ? 08003 visualiza la ayuda para el estado de SQL 08003, y ? 08

visualiza la ayuda para el código de clase 08.


v “Invocación de ayuda de mandatos desde el procesador de línea de mandatos”


v “Invocación de ayuda de mensajes desde el procesador de línea de mandatos”


Acceso a diferentes versiones del Centro de información de DB2

Para obtener los temas de DB2 Versión 9, la URL del Centro de información de

DB2 es http://publib.boulder.ibm.com/infocenter/db2luw/v9/.

Para obtener los temas de DB2 Versión 8, vaya a la URL del Centro de información

Versión 8 en: http://publib.boulder.ibm.com/infocenter/db2luw/v8/.


v “Setting up access to DB2 contextual help and documentation” en Administration

Guide: Implementation

Visualización de temas en el idioma preferido en el Centro de

información de DB2

El Centro de información de DB2 intenta visualizar los temas en el idioma

especificado en las preferencias del navegador. Si un tema no se ha traducido al

idioma preferido, el Centro de información de DB2 visualiza dicho tema en inglés.

Procedimiento:

Para visualizar temas en su idioma preferido en el navegador Internet Explorer:

1. En Internet Explorer, pulse en el botón Herramientas —> Opciones de Internet

—> Idiomas.... Se abrirá la ventana Preferencias de idioma.

2. Asegúrese de que su idioma preferido esté especificado como la primera

entrada de la lista de idiomas.

v Para añadir un nuevo idioma a la lista, pulse el botón Agregar....

Nota: La adición de un idioma no garantiza que el sistema tenga los fonts

necesarios para visualizar los temas en el idioma preferido.

v Para mover un idioma hacia el principio de la lista, seleccione el idioma y

pulse el botón Subir hasta que el idioma esté en primer lugar en la lista de

idiomas.3. Limpie la antememoria del navegador y, a continuación, renueve la página para

visualizar el Centro de información de DB2 en su idioma preferido.

Para visualizar temas en su idioma preferido en un navegador Firefox o Mozilla:

1. Seleccione el botón Herramientas —> Opciones —> Idiomas. Se visualizará el

panel Idiomas en la ventana Preferencias.

2. Asegúrese de que su idioma preferido esté especificado como la primera

entrada de la lista de idiomas.


http://publib.boulder.ibm.com/infocenter/db2luw/v9/

http://publib.boulder.ibm.com/infocenter/db2luw/v8/

v Para añadir un nuevo idioma a la lista, pulse el botón Añadir... a fin de

seleccionar un idioma en la ventana Añadir idiomas.

v Para mover un idioma hacia el principio de la lista, seleccione el idioma y

pulse el botón Subir hasta que el idioma esté en primer lugar en la lista de

idiomas.3. Limpie la antememoria del navegador y, a continuación, renueve la página para

visualizar el Centro de información de DB2 en su idioma preferido.

En algunas combinaciones de navegador y sistema operativo, puede que también

tenga que cambiar los valores regionales del sistema operativo al entorno local y al

idioma de su elección.



Actualización del Centro de información de DB2 instalado en el

sistema o en un servidor de intranet

Si ha instalado localmente un Centro de información de DB2, puede descargar

temas actualizados. El valor de 'Última actualización' que se encuentra la final de

la mayoría de los temas indica el nivel actual de ese tema.

Para determinar si hay una actualización disponible para todo el Centro de

información de DB2, busque el valor de 'Última actualización' en la página Web

inicial del Centro de información. Compare el valor contenido en la página Web

inicial instalada localmente con la fecha de la actualización descargable más

reciente contenida en http://www.ibm.com/software/data/db2/udb/support/icupdate.html. Puede actualizar el Centro de información instalado localmente si

está disponible una actualización descargable más reciente.

Para actualizar el Centro de información de DB2 instalado localmente debe:

1. Detener el Centro de información de DB2 en el sistema, y reiniciar el Centro de

información en modalidad autónoma. La ejecución del Centro de información

en modalidad autónoma impide que otros usuarios de la red accedan al Centro

de información, y permite descargar y aplicar actualizaciones.

2. Utilice la función Actualizar para determinar si hay paquetes de actualización

disponibles en IBM.

Nota: También existen actualizaciones en CD. Para conocer detalles sobre cómo

configurar el Centro de información para instalar actualizaciones desde

CD, vea los enlaces correspondientes.Si hay paquetes de actualización disponibles, utilice la función Actualizar para

descargar los paquetes. (La función actualizar sólo está disponible en

modalidad autónoma.)

3. Detenga el Centro de información autónomo y reinicie el servicio Centro de

información de DB2 en el sistema.

Procedimiento:

Para actualizar el Centro de información de DB2 instalado en el sistema o en el

servidor de intranet:

1. Detenga el servicio Centro de información de DB2.


http://www.ibm.com/software/data/db2/udb/support/icupdate.html

http://www.ibm.com/software/data/db2/udb/support/icupdate.html

v En Windows, pulse en Inicio → Panel de control → Herramientas

administrativas → Servicios. Después, pulse con el botón derecho del ratón

en el servicio Centro de información de DB2 y seleccione Detener.

v En Linux, especifique el mandato siguiente:

/etc/init.d/db2icdv9 stop

2. Inicie el Centro de información en modalidad autónoma.

v En Windows:

a. Abra una ventana de mandatos.

b. Navegue a la vía de acceso en la que está instalado el Centro de

información. Por omisión, el Centro de información de DB2 está instalado

en el directorio C:\Archivos de programa\IBM\Centro de información de

DB2\Versión 9.

c. Ejecute el archivo help_start.bat utilizando la vía de acceso

completamente calificada para el Centro de información de DB2:

<directorio de Centro de información de DB2>\doc\bin\help_start.bat

v En Linux:

a. Vaya hasta la vía de acceso en la que está instalado el Centro de

información. Por omisión, el Centro de información de DB2 está instalado

en el directorio /opt/ibm/db2ic/V9.

b. Ejecute el script help_start utilizando la vía de acceso totalmente

calificada del Centro de información de DB2:

<directorio del Centro de información de DB2>/doc/bin/help_start

Se inicia el navegador Web por omisión de los sistemas para visualizar el

Centro de información autónomo.

3. Pulse en el botón Actualizar (

). En la derecha del panel del Centro de

información, pulse en Buscar actualizaciones. Se visualiza una lista de

actualizaciones para la documentación existente.

4. Para iniciar el proceso de descarga, compruebe las selecciones que desea

descargar, después pulse en Instalar actualizaciones.

5. Cuando finalice el proceso de descarga e instalación, pulse en Finalizar.

6. Detenga el Centro de información autónomo.

v En Windows, ejecute el archivo help_end.bat utilizando la vía de acceso

completamente calificada para el Centro de información de DB2:

<directorio de Centro de información de DB2>\doc\bin\help_end.bat

Nota: El archivo help_end de proceso por lotes contiene los mandatos

necesarios para concluir sin peligro los procesos que se iniciaron

mediante el archivo help_start de proceso por lotes. No utilice

Control-C ni ningún otro método para concluir help_start.bat.

v En Linux, ejecute el script help_end utilizando la vía de acceso totalmente

calificada del Centro de información de DB2:

<directorio del Centro de información de DB2>/doc/bin/help_end

Nota: El script help_end contiene los mandatos necesarios para concluir sin

peligro los procesos que se iniciaron mediante el script help_start. No

utilice ningún otro método para concluir el script help_start.7. Reinicie el servicio Centro de información de DB2.

v En Windows, pulse en Inicio → Panel de control → Herramientas

administrativas → Servicios. Después, pulse con el botón derecho del ratón

en el servicio Centro de información de DB2 y seleccione Inicio.


v En Linux, especifique el mandato siguiente:

/etc/init.d/db2icdv9 start

El Centro de información de DB2 actualizado visualiza los temas nuevos y

actualizados.


v “Opciones de instalación del Centro de información de DB2” en Guía rápida de

iniciación para servidores DB2


v “Instalación del Centro de información de DB2 utilizando el asistente de

instalación de DB2 (Linux)” en Guía rápida de iniciación para servidores DB2

v “Instalación del Centro de información de DB2 mediante el Asistente de

instalación de DB2 (Windows)” en Guía rápida de iniciación para servidores DB2

Guías de aprendizaje de DB2

Las guías de aprendizaje de DB2 le ayudan a conocer diversos aspectos de

productos DB2. Se proporcionan instrucciones paso a paso a través de lecciones.

Antes de comenzar:

Puede ver la versión XHTML de la guía de aprendizaje desde el Centro de

información en el sitio http://publib.boulder.ibm.com/infocenter/db2help/.

Algunas lecciones utilizan datos o código de ejemplo. Consulte la guía de

aprendizaje para obtener una descripción de los prerrequisitos para las tareas

específicas.

Guías de aprendizaje de DB2:

Para ver la guía de aprendizaje, pulse el título.

Almacén de datos XML nativos

Configure una base de datos DB2 para almacenar datos XML y realizar

operaciones básicas con el almacén de datos XML nativos.

Guía de aprendizaje de Visual Explain

Analizar, optimizar y ajustar sentencias de SQL para obtener un mejor

rendimiento al utilizar Visual Explain.


v “Visual Explain overview” en Administration Guide: Implementation

Información de resolución de problemas de DB2

Existe una gran variedad de información para la resolución y determinación de

problemas para ayudarle en la utilización de productos DB2.

Documentación de DB2

Puede encontrar información sobre la resolución de problemas en la

publicación DB2 Troubleshooting Guide o en la sección Soporte y

resolución de problemas del Centro de información de DB2. En ellas

encontrará información sobre cómo aislar e identificar problemas



utilizando herramientas y programas de utilidad de diagnóstico de DB2,

soluciones a algunos de los problemas más habituales y otros consejos

sobre cómo solucionar problemas que podría encontrar en los productos

DB2.

Sitio Web de soporte técnico de DB2

Consulte el sitio Web de soporte técnico de DB2 si tiene problemas y desea

obtener ayuda para encontrar las causas y soluciones posibles. El sitio de

soporte técnico tiene enlaces a las publicaciones más recientes de DB2,

notas técnicas, Informes autorizados de análisis del programa (APAR o

arreglos de defectos), fix packs y otros recursos. Puede buscar en esta base

de conocimiento para encontrar posibles soluciones a los problemas.

Acceda al sitio Web de soporte técnico de DB2 en la dirección

http://www.ibm.com/software/data/db2/udb/support.html


v “Introduction to problem determination” en Troubleshooting Guide


Términos y condiciones

Los permisos para utilizar estas publicaciones se otorgan sujetos a los siguientes

términos y condiciones.

Uso personal: Puede reproducir estas publicaciones para su uso personal, no

comercial, siempre y cuando se mantengan los avisos sobre la propiedad. No

puede distribuir, visualizar o realizar trabajos derivados de estas publicaciones, o

de partes de las mismas, sin el consentimiento expreso de IBM.

Uso comercial: Puede reproducir, distribuir y visualizar estas publicaciones

únicamente dentro de su empresa, siempre y cuando se mantengan todos los

avisos sobre la propiedad. No puede realizar trabajos derivativos de estas

publicaciones, ni reproducirlas, distribuirlas o visualizarlas, ni de partes de las

mismas fuera de su empresa, sin el consentimiento expreso de IBM.

Excepto lo expresamente concedido en este permiso, no se conceden otros

permisos, licencias ni derechos, explícitos o implícitos, sobre las publicaciones ni

sobre ninguna información, datos, software u otra propiedad intelectual contenida

en el mismo.

IBM se reserva el derecho de retirar los permisos aquí concedidos cuando, a su

discreción, el uso de las publicaciones sea en detrimento de su interés o cuando,

según determine IBM, las instrucciones anteriores no se cumplan correctamente.

No puede descargar, exportar ni volver a exportar esta información excepto en el

caso de cumplimiento total con todas las leyes y regulaciones vigentes, incluyendo

todas las leyes y regulaciones sobre exportación de los Estados Unidos.

IBM NO GARANTIZA EL CONTENIDO DE ESTAS PUBLICACIONES. LAS

PUBLICACIONES SE PROPORCIONAN ″TAL CUAL″ Y SIN GARANTÍA DE

NINGUNA CLASE, NI EXPLÍCITA NI IMPLÍCITA, INCLUYENDO PERO SIN

LIMITARSE A LAS GARANTÍAS IMPLÍCITAS DE COMERCIALIZACIÓN, NO

VULNERACIÓN E IDONEIDAD PARA UN FIN DETERMINADO.


http://www.ibm.com/software/data/db2/udb/support.html

Apéndice C. Avisos

Es posible que IBM no comercialice en todos los países algunos productos,

servicios o características descritos en este manual. Consulte al representante local

de IBM para obtener información sobre los productos y servicios que actualmente

pueden adquirirse en su zona. Cualquier referencia a un producto, programa o

servicio de IBM no pretende afirmar ni implicar que sólo se pueda utilizar dicho

producto, programa o servicio de IBM. En su lugar se puede utilizar cualquier

producto, programa o servicio funcionalmente equivalente que no vulnere ninguno

de los derechos de propiedad intelectual de IBM. Sin embargo, es responsabilidad

del usuario evaluar y verificar el funcionamiento de cualquier producto, programa

o servicio que no sea de IBM.

IBM puede tener patentes o solicitudes de patentes en tramitación que afecten al

tema tratado en este documento. La posesión de este documento no confiere

ninguna licencia sobre dichas patentes. Puede realizar consultas sobre licencias

escribiendo a:

IBM Director of Licensing

IBM Corporation

North Castle Drive

Armonk, NY 10504-1785

EE.UU.

Para realizar consultas sobre licencias referentes a información de doble byte

(DBCS), puede ponerse en contacto con el Departamento de Propiedad Intelectual

de IBM de su país/región o escribir a:

IBM World Trade Asia Corporation

Licensing

2-31 Roppongi 3-chome, Minato-ku

Tokio 106, Japón

El párrafo siguiente no es aplicable al Reino Unido ni a ningún país/región en

donde tales disposiciones sean incompatibles con la legislación local:

INTERNATIONAL BUSINESS MACHINES CORPORATION PROPORCIONA

ESTA PUBLICACIÓN “TAL CUAL”, SIN GARANTÍA DE NINGUNA CLASE, NI

EXPLÍCITA NI IMPLÍCITA, INCLUIDAS, PERO SIN LIMITARSE A ELLAS, LAS

GARANTÍAS IMPLÍCITAS DE NO VULNERACIÓN DE DERECHOS,

COMERCIALIZACIÓN O IDONEIDAD PARA UN FIN DETERMINADO. Algunos

estados no permiten la exclusión de garantías expresas o implícitas en

determinadas transacciones, por lo que es posible que esta declaración no sea

aplicable en su caso.

Esta publicación puede contener inexactitudes técnicas o errores tipográficos.

Periódicamente se efectúan cambios en la información aquí contenida; dichos

cambios se incorporarán a las nuevas ediciones de la publicación. IBM puede

efectuar, en cualquier momento y sin previo aviso, mejoras y cambios en los

productos y programas descritos en esta publicación.

Las referencias hechas en esta publicación a sitios Web que no son de IBM se

proporcionan sólo para la comodidad del usuario y no constituyen un aval de esos

sitios Web. La información contenida en estos sitios Web no forma parte de la

información del presente producto IBM y el usuario es responsable de la

utilización de dichos sitios.


IBM puede utilizar o distribuir cualquier información que se le facilite de la

manera que considere adecuada, sin contraer por ello ninguna obligación con el

remitente.

Los licenciatarios de este programa que deseen obtener información sobre él con el

fin de habilitar: (i) el intercambio de información entre programas creados de

forma independiente y otros programas (incluido éste) y (ii) el uso mutuo de la

información intercambiada, deben ponerse en contacto con:

IBM Canada Limited

Office of the Lab Director

8200 Warden Avenue

Markham, Ontario

L6G 1C7

CANADÁ

Dicha información puede estar disponible, sujeta a los términos y condiciones

apropiados, incluido en algunos casos el pago de una tarifa.

El programa bajo licencia descrito en este documento y todo el material bajo

licencia asociado a él, los proporciona IBM según los términos del Acuerdo de

Cliente de IBM, el Acuerdo Internacional de Programas Bajo Licencia de IBM o

cualquier acuerdo equivalente entre el usuario e IBM.

Los datos de rendimiento contenidos en este documento se obtuvieron en un

entorno controlado. Por lo tanto, los resultados obtenidos en otros entornos

operativos pueden variar significativamente. Algunas mediciones pueden haberse

realizado en sistemas experimentales y no es seguro que estas mediciones sean las

mismas en los sistemas disponibles comercialmente. Además, algunas mediciones

pueden haberse calculado mediante extrapolación. Los resultados reales pueden

variar. Los usuarios del presente manual deben verificar los datos aplicables para

su entorno específico.

La información referente a productos que no son de IBM se ha obtenido de los

proveedores de esos productos, de sus anuncios publicados o de otras fuentes

disponibles públicamente. IBM no ha probado esos productos y no puede

confirmar la exactitud del rendimiento, la compatibilidad ni ninguna otra

afirmación referente a productos que no son de IBM. Las preguntas sobre las

prestaciones de productos que no son de IBM deben dirigirse a los proveedores de

esos productos.

Todas las declaraciones de intenciones de IBM están sujetas a cambio o cancelación

sin previo aviso, y sólo representan objetivos.

Este manual puede contener ejemplos de datos e informes que se utilizan en

operaciones comerciales diarias. Para ilustrarlos de la forma más completa posible,

los ejemplos incluyen nombres de personas, empresas, marcas y productos. Todos

estos nombres son ficticios y cualquier similitud con nombres y direcciones

utilizados por una empresa real es totalmente fortuita.

LICENCIA DE COPYRIGHT:

Este manual puede contener programas de aplicaciones de ejemplo escritos en

lenguaje fuente, que muestran técnicas de programación en diversas plataformas

operativas. Puede copiar, modificar y distribuir estos programas de ejemplo como

desee, sin pago alguno a IBM con la intención de desarrollar, utilizar, comercializar

o distribuir programas de aplicaciones de acuerdo con la interfaz de programación


de aplicaciones correspondiente a la plataforma operativa para la que están escritos

los programas de ejemplo. Estos ejemplos no se han probado exhaustivamente bajo

todas las condiciones. Por lo tanto, IBM no puede asegurar ni implicar la

fiabilidad, utilidad o función de estos programas.

Cada copia o parte de estos programas de ejemplo o cualquier trabajo derivado

debe incluir una nota de copyright como la siguiente:

© (nombre de la empresa) (año). Partes de este código proceden de programas de

ejemplo de IBM Corp. © Copyright IBM Corp. _entre el o los años_. Reservados

todos los derechos.

Marcas registradas

Los nombres de empresas, productos o servicios identificados en la biblioteca de

documentación de DB2 Versión 9 pueden ser marcas registradas o marcas de

servicios de International Business Machines Corporation o de otras empresas. La

información sobre marcas registradas de IBM Corporation en los Estados Unidos

y/o en otros países está ubicada en http://www.ibm.com/legal/copytrade.shtml.

Los términos siguientes son marcas registradas de otras empresas y se han

utilizado como mínimo en uno de los documentos de la biblioteca de

documentación de DB2:

Microsoft, Windows, Windows NT y el logotipo de Windows son marcas

registradas de Microsoft Corporation en los Estados Unidos y/o en otros países.

Intel, Itanium, Pentium y Xeon son marcas registradas de Intel Corporation en los

Estados Unidos y/o en otros países.

Java y todas las marcas registradas basadas en Java son marcas registradas de Sun

Microsystems, Inc. en los Estados Unidos y/o en otros países.

UNIX es una marca registrada de The Open Group en los Estados Unidos y/o en

otros países.

Linux es una marca registrada de Linus Torvalds en los Estados Unidos y/o en

otros países.

Otros nombres de empresas, productos o servicios, pueden ser marcas registradas

o marcas de servicio de otras empresas.

Apéndice C. Avisos 427

http://www.ibm.com/legal/copytrade.shtml

Índice

Caracteres

Especiales#ifdefs

restricciones para C/C++ 112

.NETarchivos de proceso por lotes 221

Aactualizaciones

Centro de información 421

Centro de información de DB2 421

AIXaplicaciones C

opciones de compilación y

enlace 234

aplicaciones C++opciones de compilación y

enlace 235

aplicaciones COBOL de IBMcreación 246


enlace 259

aplicaciones COBOL de Micro Focusopciones de compilación y

enlace 260

funciones definidas por el usuario en

C++creación con archivos de

configuración 386

procedimientos almacenados en C++creación con archivos de

configuración 384

rutinas Copciones de compilación y

enlace 373

rutinas C++opciones de compilación y

enlace 374

rutinas COBOL de IBMcreación 396


enlace 391

rutinas COBOL de Micro Focusopciones de compilación y

enlace 392

SQL incorporado en C++creación con archivos de

configuración 230

almacenamientoasociación para albergar filas 158

declarar suficientes entidades

SQLVAR 153

API Bindcreación de paquetes 214

vinculación diferida 217

API GET ERROR MESSAGErecuperación de mensajes de

error 191

API GET ERROR MESSAGE

(continuación)variables REXX predefinidas 143

aplicacionesmigración 269

aplicaciones C/C++acceso a bases de datos de varias

hebras 31

Archivos de entrada y salida 43

Ejecución de sentencias de SQL

estático 151

aplicaciones COBOLArchivos de entrada y salida 43

Ejecución de sentencias de SQL

estático 151

Variables del lenguaje principal 119

restricciones 119

aplicaciones FORTRANArchivos de entrada y salida 43


aplicaciones multiconexiónarchivos de creación 221

creación de C/C++ de Windows 232

aplicaciones multihebraarchivos de creación 221

creación con C/C++ de

Windows 227

aplicaciones REXX 265


APPC (Comunicación Avanzada

Programa a Programa)manejo de interrupciones 194

archivosdeclaraciones de referencia en

C/C++ 106

archivos de configuraciónpara VisualAge C++ en AIX 229

VisualAge 225

archivos de creación 221

Archivos de inclusiónBibliotecas 47

archivos de proceso por lotes 221

archivos de vinculación 198, 204

compatibilidad con versiones

anteriores 216

REXX 266

soporte para aplicaciones REXX 266

archivos includerequisitos

C/C 48

COBOL 50

FORTRAN 53

SQLpara C/C 48

para COBOL 50

para FORTRAN 53

SQL1252ACOBOL 50

FORTRAN 53

SQL1252BCOBOL 50

archivos include (continuación)SQL1252B (continuación)

FORTRAN 53

SQLADEF para C/C++ 48

SQLAPREPpara C/C 48

para COBOL 50

para FORTRAN 53

SQLCApara C/C 48

para COBOL 50

para FORTRAN 53

SQLCA_92COBOL 50

FORTRAN 53

SQLCACNFORTRAN 53

SQLCACSFORTRAN 53

SQLCLI para C/C++ 48

SQLCLI1 para C/C++ 48

SQLCODESpara C/C 48

para COBOL 50

para FORTRAN 53

SQLDACOBOL 50

para C/C 48

para FORTRAN 53

SQLDACTFORTRAN 53

SQLE819Apara C/C 48

para COBOL 50

para FORTRAN 53

SQLE819Bpara C/C 48

para COBOL 50

para FORTRAN 53

SQLE850Apara C/C 48

para COBOL 50

para FORTRAN 53

SQLE850Bpara C/C 48

para COBOL 50

para FORTRAN 53

SQLE932Apara C/C 48

para COBOL 50

para FORTRAN 53

SQLE932Bpara C/C 48

para COBOL 50

para FORTRAN 53

SQLEAUpara C/C 48

para COBOL 50

para FORTRAN 53

SQLENVCOBOL 50


archivos include (continuación)SQLENV (continuación)

FORTRAN 53

para C/C 48

SQLETSDCOBOL 50

SQLEXT para C/C++ 48

SQLJACB para C/C++ 48

SQLMONCOBOL 50

FORTRAN 53

para C/C 48

SQLMONCTpara COBOL 50

SQLSTATEpara C/C 48

para COBOL 50

para FORTRAN 53

SQLSYSTM para C/C++ 48

SQLUDF para C/C++ 48

SQLUTBCQCOBOL 50

SQLUTBSQCOBOL 50

SQLUTILpara C/C 48

para COBOL 50

para FORTRAN 53

SQLUV para C/C++ 48

SQLUVEND para C/C++ 48

SQLXA para C/C++ 48

ubicaciónen COBOL 7

área de comunicaciones de SQL

(SQLCA) 56

áreas reutilizablespara UDF y métodos 285

plataformas de 32 y 64 bits 289

avisos 425

ayudapara sentencias de SQL 419

visualizar 420

Bbases de datos

accesovarias hebras 31

utilizando contextos distintos 31

bibliotecas compartidasrutina de revinculación 387

blob, tipo de C/C++ 60

blob_file, tipo de C/C++ 60

BLOB-FILE, tipo de COBOL 67

blob_locator, tipo de C/C++ 60

BLOB-LOCATOR, tipo de COBOL 67

bloqueosliberación de cursor 181

CC

aplicacionescreación en UNIX 225

creación en Windows 227

C (continuación)aplicaciones (continuación)

opciones de compilación en

AIX 234


HP-UX 236


Linux 239


Solaris 242


Windows 245

aplicaciones multiconexióncreación en Windows 232

aplicaciones multihebraWindows 227


Archivos de proceso por lotes 268

archivos del programa de utilidad de

comprobación de errores 223

ejemplos 405

entorno de desarrollo 44

funcionesestilos de parámetros 324

Plantilla de aplicación 44

procedimientosconjuntos de resultados 358

estilos de parámetros 320

rutinas 314

archivo de inclusión 318

área reutilizable como parámetro

de función 329

cláusula PROGRAM TYPE 330

conjuntos de resultados 326

creación 362, 363, 371

creación en UNIX 365


crear 360

diseño 316


estructura dbinfo como

parámetro 327

herramientas de desarrollo 316


AIX 373


HP-UX 376


Linux 378


Solaris 381


Windows 384

parámetros 319

parámetros de indicador de

nulo 320

pase de parámetros 326

rutinas de 32 bits en un servidor

de bases de datos de 64 bits 307

sintaxis para pasar

argumentos 342

soporte de desarrollo 315

tipos de datos de SQL soportados

en 331

C++aplicaciones


C++ (continuación)aplicaciones (continuación)


AIX 235


HP-UX 238


Linux 241


Solaris 244


Windows 245

aplicaciones multiconexióncreación en Windows 232

aplicaciones multihebraWindows 227

archivos de configuración VisualAge

en AIX 229




decoración de tipos para cuerpos de

rutinas 356

funcionesestilos de parámetros 324

procedimientosconjuntos de resultados 358


rutinas 314

archivo de inclusión 318


de función 329



creación 362, 363, 371


crear 360

diseño 316


estructura dbinfo como

parámetro 327



AIX 374


HP-UX 377


Linux 380


Solaris 382


Windows 384

parámetros 319


nulo 320






en 331

C# .NETarchivos de proceso por lotes 221

calificación y operaciones de miembros

en C/C++ 110

campo SQLSTATE 190


CAST FROM, cláusulamanejo de tipos de datos 334

Centro de informaciónactualización 421

ver en idiomas diferentes 420

versiones 420

Centro de información de DB2actualización 421

ver en idiomas diferentes 420

versiones 420

char, tipo de datos de C/C++ 60

cláusula FOR UPDATE 188

clientesinvocar procedimientos almacenados

en REXX 175

CLOB (character large object)C/C++, conversión 60

tipo de datosC/C++ 112

COBOL 67

FORTRAN 70

REXX 72

variables indicadoras 77

CLOB-FILE, tipo de COBOL 67

clob_file, tipo de datos de C/C++ 60

CLOB-LOCATOR, tipo de COBOL 67

clob_locator, tipo de datos de C/C++ 60

COBOL, lenguajeAIX

compilador de IBM 256

compilador de Micro Focus 257

aplicaciones COBOL de IBMcreación en AIX 246



AIX 259


Windows 263

aplicaciones de Micro Focuscreación en UNIX 248



AIX 260


HP-UX 261


Linux 262


Solaris 261


Windows 264




archivos include 50

Comentarios 150

Conexión con base de datos 58

consideraciones sobre EUC en chino

(tradicional) 129

consideraciones sobre EUC en

japonés 129

declaración de variables del lenguaje

principal 120

declaración de variables gráficas del

lenguaje principal 125

declaraciones de datos LOB 126

COBOL, lenguaje (continuación)declaraciones de localizadores de

LOB 127

declaraciones de referencias de

archivos 128

Desconexión de base de datos 195

ejemplos 408

estructuras de sistema principal 130

FOR BIT DATA 129

HP-UXutilización del compilador de

Micro Focus 258

Linuxcompilador de Micro Focus 255

nomenclatura de variables del


procedimientos almacenados 388

REDEFINES 128

restricciones 28

rutinas COBOL de IBMcreación en AIX 396



AIX 391


Windows 395

rutinas de Micro Focuscreación en UNIX 398



AIX 392


HP-UX 393


Linux 394


Solaris 393


Windows 396

sentencias de SQL incorporado 7

Solariscompilador de Micro Focus 258

tablas de indicadores 132

tipos de datos 67

variables de lenguaje principal de tipo

carácter y longitud fija, sintaxis 123

variables del lenguaje principal

numéricas 122

variables SQLCODE 122

variables SQLSTATE 122

Windowscompilador de IBM 253

compilador de Micro Focus 254

COBOL, tipos de datosBINARY 121

BLOB 67

BLOB-FILE 67

BLOB-LOCATOR 67

CLOB 67

CLOB-FILE 67

CLOB-LOCATOR 67

COMP 121

COMP-1 67

COMP-3 67

COMP-4 121

COMP-5 67

DBCLOB 67

COBOL, tipos de datos (continuación)DBCLOB-FILE 67

DBCLOB-LOCATOR 67

PICTURE (PIC), cláusula 67

USAGE cláusula 67

códigos de finalización 56

códigos de resultados 56

códigos de retornodeclaración del SQLCA 56

códigos satisfactorios 56

colocación en serieestructuras de datos 34

SQL, ejecución de sentencias 31

columna, tipos decrear

C/C++ 60

COBOL 67

FORTRAN 70

columnasestablecimiento de valores nulos 81

tipos de datos de SQL soportados 77

coma flotante, parámetro 334

comentariossentencia de SQL incorporado 9

SQL, normas 5, 7, 8

compartidas, bibliotecasrutina de revinculación 387

compilaciónvisión general 209

compiladores 12

crear archivos para 221

utilización de COBOL de IBM en

AIX 256

utilización de COBOL de IBM en

Windows 253

utilización de COBOL de Micro Focus

en AIX 257


en HP-UX 258


en Solaris 258


en Windows 254

comportamiento de ejecución,

DYNAMICRULES 211

comportamiento de invocación,

DYNAMICRULES 211

comportamiento de vinculaciónDYNAMICRULES 211

comprobación de erroresarchivos de programas de

utilidad 223

consideraciones sobre programaciónC/C++ 27

FORTRAN 29

REXX 30

consultasactualizable 188

suprimible 188

contacto con IBM 431

contextosdependencias de aplicación entre 36

dependencias de base de datos

entre 36

establecimiento en aplicaciones DB2

de varias hebrasdescripción 31

Índice 431

copia de seguridadbibliotecas de rutinas externas 305

correlaciones de tipos de datos 59

creación de aplicacionessoporte de 32 y 64 bits 26

utilización de línea mandatos 268

crearrutinas 312, 360

C/C++ 316

CREATE FUNCTION, sentenciaCAST FROM, cláusula 334

cláusula PARAMETER STYLE 324

RETURNS, cláusula 334

CREATE PROCEDURE, sentencia 171

cláusula PARAMETER STYLE 320


cursorescolocación al final de la tabla 183

comportamientocon sentencia COMMIT 181

consideraciones sobre COMMIT 181

consideraciones sobre

ROLLBACK 181

declaraciónen programas de SQL estático 184

filasactualización 188

supresión 188

finalidad 176, 180

liberar, comportamiento del

bloqueo 181

nombres, REXX 9

paquete invalidado, recuperar

filas 181

procesarcon estructura de SQLDA 159

en SQL dinámico 185

resumen 180

programa de ejemplo 189

recuperación de varias filas 180

recuperar filas 184

sólo lecturaconsideraciones sobre la unidad de

trabajo 181

declaración 184

SQL dinámico, programa de

ejemplo 187

SQL estático, ejemplo 186

unidad de trabajofinalización 181

varios en aplicación 180

WITH HOLDcomportamiento tras

COMMIT 181

comportamiento tras

ROLLBACK 181

revinculación de paquete durante

unidad de trabajo 181

Ddatos

actualización 188

recuperacióncon SQL estático 176

segunda vez 178

recuperados, guardar 177

datos (continuación)recuperados anteriormente

actualización 180

desplazamiento 177

segunda recuperación 179

supresión 188

datos gráficos de longitud variable

terminados en nulo 60

DB2ARXCS.BND, archivo de vinculación

para REXX 266

DB2ARXNC.BND, archivo de vinculación

para REXX 266

DB2ARXRR.BND, archivo de vinculación

para REXX 266

DB2ARXRS.BND, archivo de vinculación

para REXX 266

DB2ARXUR.BND, archivo de vinculación

para REXX 266

db2bfd, programa de utilidad de

descripción de archivos de

vinculación 210

DB2GENERAL, estilo de parámetros para

rutinas externas 298

DB2INCLUDEvariable de entorno 7

DB2SQL, estilo de parámetros para


DBCLOB-FILE, tipo de COBOL 67

dbclob_file, tipo de datos de C/C++ 60

DBCLOB-LOCATOR, tipo de COBOL 67

dbclob_locator, tipo de datos de

C/C++ 60

dbinfo, argumentofunciones de tabla 281

DDL (lenguaje de definición de datos)rendimiento de SQL dinámico 22

declaraciónvariables del lenguaje principal,

normas 74


declaración gráfica de la forma

estructurada VARGRAPHICC/C++, sintaxis 101

declaraciones de referencias de archivos

en REXX 148

decoración de tiposcuerpos de rutinas en C++ 356

determinación de problemasguías de aprendizaje 423

información en línea 423

diseño de aplicaciónarchivos include, COBOL 50

consideraciones sobre EUC en japonés

y chino tradicional en COBOL 129

creación de estructura de SQLDA,

directrices 159


SQLVAR 153

descripción de sentencia SELECT 157

desplazarse por datos recuperados

anteriormente 177

ejecución de sentencias sin

variables 21

guardar peticiones de usuario

final 166

manejo de errores, directrices 57

pasar datos, directrices 163

diseño de aplicación (continuación)proceso de cursor 181

recepción de valores NULL 81

recuperación de datos por segunda

vez 178

REXX, rutinas de registro 145

sentencias de lista variable,

proceso 165

utilización de marcadores de

parámetros 169

versiones de paquetes con mismo

nombre 219

DML (lenguaje de manipulación de

datos)rendimiento de SQL dinámico 22

documentación 415, 416

términos y condiciones de uso 424

DYNAMICRULEScomportamiento 211

DYNAMICRULES, opción de

precompilación/vinculaciónefectos en SQL dinámico 211

Eejemplos

C 405

COBOL 408

declaración de localizador de archivos

CLOBFORTRAN 139

declaración de referencias de archivos

BLOBCOBOL 128

FORTRAN 140

declaraciones de datos BLOB 103

declaraciones de datos CLOB 103

declaraciones de datos DBCLOB 103

declarar BLOBCOBOL 126

FORTRAN 138

declarar CLOBCOBOL 126

FORTRAN 138

declarar DBCLOB, COBOL 126

declarar localizador de BLOB,

COBOL 127

ejemplo de sección de declaración de

SQL para tipos de datos SQL

soportados 90

IBM COBOL 246

localizador de CLOB 105

marcadores de parámetros, utilizados

en búsqueda y actualización 170

miembros de datos de clase en

sentencias de SQL 108

programa REXX, registrar SQLEXEC,

SQLDBS y SQLDB2 145

referencia de archivos CLOB 106

sintaxis, variables de lenguaje

principal de tipo carácter,

FORTRAN 136

enganche, estado con varias hebras 31

enlacedescripción 209

entidades SQLVARdeclarar número suficiente 156


entidades SQLVAR (continuación)número de variables, declarar 153

entorno, API dearchivo de inclusión

C/C++ 48

COBOL 50

FORTRAN 53

Esquema de paquete 204

estándar FIPS 127-2declaración de SQLSTATE y

SQLCODE como variables del


estructura de SQLCAarchivo de inclusión para C/C++ 48

archivos includeaplicaciones COBOL 50

aplicaciones FORTRAN 53

avisos 81

campo SQLCODE 190

campo SQLSTATE 190

campo SQLWARN1 81

requisitos 190

varias definiciones 57

visión general 190

estructura de SQLDAasociación con sentencia

PREPARE 21

colocación de información sobre

sentencia preparada en 21

crear 159

declaración 153


SQLVAR 156

determinación de tipo de sentencia

arbitraria 164

pasar datos 163

preparar sentencias con estructura

mínima 154

estructura SQLCHARpasar datos con 163

estructura SQLWARN 190

estructuras de datosdefinidas por el usuario con varias

hebras 34

EXEC SQL INCLUDE SQLCA 34

expansión de macrolenguaje C/C++ 112

Extended UNIX Code (EUC)chino (tradicional)

C/C++ 110

consideraciones en COBOL 129

FORTRAN 141

JaponésC/C++ 110

FORTRAN 141

japonés y chino tradicionalconsideraciones en COBOL 129

Ffilas

captación tras paquete

invalidado 181

posicionamiento en tabla 183

recuperación de varias 180

recuperación mediante SQLDA 158

filas (continuación)segunda recuperación

métodos 178

orden de filas 179

FORTRAN, lenguajearchivos include 53

Comentarios 150


consideraciones sobre el chino

tradicional 141

consideraciones sobre el japonés 141


programación 29


declaraciones de localizadores de

LOB 139


archivos 140

incorporación de sentencias de

SQL 8

juegos de caracteres de varios

bytes 140

restricciones 133

sección de declaración de SQL 134

tipos de datos 70

variables del lenguaje principaldeclaración 134

denominación 133

referencia 8


numéricas 135




FORTRAN, tipos de datosBLOB 70

BLOB_FILE 70

BLOB_LOCATOR 70

CHARACTER*n 70

CLOB 70

CLOB_FILE 70

CLOB_LOCATOR 70

conversión con DB2 70

INTEGER*2 70

INTEGER*4 70

REAL*2 70

REAL*4 70

REAL*8 70

fuentesaplicaciones de SQL incorporado 201

funcionesexternas

características 277

parámetroscláusula PARAMETER

STYLE 324

funciones de preprocesadory el precompilador de SQL 112

funciones de tablafunciones de tabla definidas por el

usuario 281

modelo de ejecución de Java 284

funciones definidas por el usuario (UDF)archivos de configuración de C++ de

AIX 386

C/C++argumentos 334

funciones definidas por el usuario

(UDF) (continuación)C/C++ (continuación)

CLOB, tipo de datos 334

parámetros 334

REAL, tipo de datos 334

Tipo de datos BIGINT 334

tipo de datos BLOB 334

tipo de datos CHAR 334

tipo de datos DBCLOB 334

tipo de datos DOUBLE 334

tipo de datos FLOAT 334

tipo de datos INTEGER 334

tipo de datos LONG

VARCHAR 334

tipo de datos SMALLINT 334

tipo de datos VARGRAPHIC 334

VARCHAR FOR BIT DATA, tipo

de datos 334

de tablaSQL-result, argumento 281

SQL-result-ind, argumento 281

DETERMINISTIC 285

devolución de datos 334

guardar el estado 285

modificador FOR BIT DATA 334

NOT DETERMINISTIC 285

parámetros de fecha 334

reentrantes 285

SCRATCHPAD, opción 285

funciones definidas por el usuario (UDF)

para tablasmodelo de proceso 282

funciones escalaresmodelo de proceso 280

visión general 278

Ggenerador de declaraciones db2dclgn

declaración de variables del lenguaje

principal 77

GENERAL, estilo de parámetros para


GENERAL WITH NULLS, estilo de

parámetros para rutinas externas 298

GRAPHIC, parámetro 334

guías de aprendizajeresolución y determinación de

problemas 423

Visual Explain 423

Hhebras

variasconsideraciones sobre aplicaciones

UNIX 35

consideraciones sobre página de

códigos 35

consideraciones sobre página de

códigos de país/región 35

dependencias de aplicación entre

contextos 36

dependencias de base de datos

entre contextos 36

Índice 433

hebras (continuación)varias (continuación)

problemas potenciales 36

recomendaciones 34

utilización en aplicaciones DB2 31

HP-UXopciones de compilación y enlace

aplicaciones C 236

aplicaciones C++ 238

aplicaciones COBOL de Micro

Focus 261

rutinas C 376

rutinas C++ 377

rutinas COBOL de Micro

Focus 393

Iindicaciones horarias

al precompilar 208

información de errorSQLCODE 83

SQLSTATE 83

instantáneas de Explaindurante vinculación 216

interfaces de programación de

aplicaciones (API)para establecer contextos entre hebras

sqleAttachToCtx() 31

sqleBeginCtx() 31

sqleDetachFromCtx() 31

sqleEndCtx() 31

sqleGetCurrentCtx() 31

sqleInterruptCtx() 31

sqleSetTypeCtx() 31

sintaxis para REXX 173

interrupción SIGUSR1 194

interrupciones, SIGUSR1 194

Jjaponés y chino tradicional, juegos de

códigos EUCconsideraciones en COBOL 129

Javaestilo de parámetros para rutinas

externas 298

modelo de ejecución de las funciones

de tabla 284

juegos de caracteresvarios bytes, FORTRAN 140

juegos de códigos en chino (tradicional)consideraciones en COBOL 129

consideraciones para C/C++ 110

FORTRAN 141

juegos de códigos en japonésconsideraciones para C/C++ 110

FORTRAN 141

LLANGLEVEL, opción de precompilación

MIA 60

SAA1 60

variables SQL92E y SQLSTATE o

SQLCODE 92, 122, 135

lectura repetible (RR)método 177

lenguaje C/C++archivos include necesarios 48

Comentarios 150


consideraciones sobre EUC en chino

(tradicional) 110

consideraciones sobre EUC en

japonés 110


programación 27

declaración de variables gráficas del


declaración gráfica de la forma

estructurada VARGRAPHIC,

sintaxis 101



LOB 105


archivos 106


FOR BIT DATA 112

inicialización de variables del lenguaje

principal 112

manejo de series terminadas en

nulo 117

miembros de datos de clase 108

opción WCHARTYPE del

precompilador 98

operador de calificación,

restricción 110

operador de miembro, restricción 110

Procedimientos almacenados 171

puntero a tipo de datos 107

sentencias de SQL incorporado 5

soporte de estructura de sistema

principal 114

sqldbchar, tipo de datos 97

tablas de indicadores 116

tipo de datos wchart 97

tipos de datospara funciones 65

para métodos 65

para procedimientos

almacenados 65

soportados 60

tipos de datos soportados 60

variables del lenguaje principaldeclaración 89

denominación 88

finalidad 86


numéricas 92

variables gráficas del lenguaje

principal 96, 102



lenguaje REXXAPI

SQLDB2 30

SQLDBS 30

SQLEXEC 30

archivos de vinculación 266

campos decimales de SQLDArecuperar datos 175

lenguaje REXX (continuación)Comentarios 150



programación 30

creación de aplicaciones para

Windows 267

datos LOB 146


LOB 147


archivos LOB 148


ejecución de aplicaciones 265

ejemplos 412

identificadores de cursor 9

incorporación de sentencias de

SQL 9

inicialización de variables 172

invocar procedimientos

almacenados 175

llamada al CLP de DB2 173

procedimientos almacenadosconsideraciones sobre el

servidor 175

llamada 172

visión general 172

registro de rutinas 145

registro de SQLEXEC, SQLDBS y

SQLDB2 145

restricciones 142

sentencias de SQL 9

sintaxis de API 173

tipos de datos 72

variables del lenguaje principaldenominación 142

referencia 142

variables del lenguaje principal LOB,

borrado 149


variables predefinidas 143

Linuxaplicaciones C


enlace 239

aplicaciones C++opciones de compilación y

enlace 241


enlace 262

Bibliotecas 271

Micro Focus COBOLconfiguración del compilador 255

rutinas Copciones de compilación y

enlace 378

rutinas C++opciones de compilación y

enlace 380


enlace 394

LOB (large object), tipos de datosdeclaraciones de datos en

C/C++ 103


LOB (large object), tipos de datos

(continuación)declaraciones de localizador en

C/C++ 105

long, tipo de datos de C/C++ 60

long int, tipo de datos de C/C++ 60

long long, tipo de datos de C/C++ 60

long long int, tipo de datos de

C/C++ 60

LONG VARGRAPHICparámetro de las UDF 334

Mmandato BIND 268

creación de paquetes 214

mandato BIND PACKAGEvolver a vincular 215

mandato PRECOMPILE 198, 203, 268

mandato RUNSTATS 25

manejadores de excepcionesconsideraciones sobre COMMIT y

ROLLBACK 194

finalidad 194

manejadores de interrupcionesconsideraciones sobre COMMIT y

ROLLBACK 194

finalidad 194

manejadores de señalescon sentencias de SQL 194

consideraciones sobre COMMIT y

ROLLBACK 194

finalidad 194

manejo de erroresarchivos include

C/C++ 48

COBOL 50

FORTRAN 53

estructuras de SQLCAutilizar 56

sentencia WHENEVER 57

manejo de interrupciones con sentencias

de SQL 194

manuales imprimidossolicitud 418

marcador de parámetros tipificado 169

marcadores de parámetrosejemplo de programación 170

en proceso de sentencias

arbitrarias 164

entradas SQLVAR 169

tipificados 169

uso en SQL dinámico 169

mensajes de avisotruncamiento 81

mensajes de errordistintivo de condición de aviso 190

distintivo de condición de error 190

distintivo de condición de

excepción 190

estructura de SQLCA 190

estructura SQLWARN 190

manejo de errores 56

SQLSTATE 190

métodosexternas


MIA LANGLEVEL, opción de

precompilación 60

miembros de datos de clase 108

migraciónSQL incorporado

aplicaciones 269

multibyte, consideraciones sobrejaponés y chino tradicional, juegos de

códigos EUCCOBOL 129

juegos de códigos en chino

(tradicional)C/C 110

FORTRAN 141

juegos de códigos en japonésC/C 110

FORTRAN 141

Nniveles de aislamiento

lectura repetible (RR) 177

NUMERIC, parámetro 334

OObject REXX para Windows 267

ejemplos 412

OLE, rutinas desintaxis para pasar argumentos 342

opción de vinculación EXPLSNAP 216

opción de vinculación FUNCPATH 216

opción WCHARTYPE del precompiladordirectrices 98

tipos de datos disponibles con la

opción NOCONVERT 60

opciones de vinculaciónEXPLSNAP 216

FUNCPATH 216

QUERYOPT 216

operador de miembro, restricción en

C/C 110

optimizadorconsideraciones sobre SQL estático y

dinámico 22

Ppáginas de códigos


vinculación 216

paquetes 204

crear 214

errores de indicación horaria 208

inoperativo 215

no válidoestado 215

revinculación durante unidad de

trabajocomportamiento de cursor 181

soporte de aplicaciones REXX 266

versiones, privilegios 219

versiones con mismo nombre 219

parámetrosestilos para rutinas externas 298

rutinas C/C++ 319

parámetros de COLLECTION 220

pase de contextos entre hebras 31

PICTURE (PIC), cláusula en los tipos de

COBOL 67

plataformas soportadas32 y 64 bits 26

precompilación 201

acceso a servidor de aplicaciones de

sistema principal o AS/400 a través

de DB2 Connect 201

acceso a varios servidores 201

indicaciones horarias 208

programa de utilidad del

marcador 201

señal de coherencia 208

soporte de sentencias de SQL

dinámico 21

precompiladorFORTRAN 29

lenguaje C/C++ 110

PREPARE, sentenciafinalidad 21

proceso de sentencias arbitrarias 164

Privilegios de paquete 219

procedimientosC/C++


parámetroscláusula PARAMETER STYLE de

SQL 320

procedimientos almacenadosaplicaciones REXX 172

archivos de configuración de C++ de

AIX 384

COBOL 388

inicializaciónvariables REXX 172

llamadaREXX 172

sentencia CALL 171

Tipos de parámetros 171

procesador de línea de mandatos (CLP)llamada desde aplicación REXX 173

programa marcador para la

precompilación 201

programas de aplicaciónCOBOL

variables de lenguaje principal,

ejemplo 120

REXXinvocar procedimientos

almacenados, consideraciones

sobre el servidor 175

rutinas de lista de salida 194

SQL incorporado, visión general 3

programas de utilidad, API dearchivo de inclusión para aplicaciones

C/C++ 48

archivos includeaplicaciones COBOL 50


puntos muertosen aplicaciones de varias hebras 36

Índice 435

Qqueryopt, opción de

precompilación/vinculaciónconsideraciones sobre página de

códigos 216

RREAL*2 FORTRAN, tipo de datos de

SQL 70

REAL*4 FORTRAN, tipo de datos de

SQL 70

REAL*8 FORTRAN, tipo de datos de

SQL 70

recuperar datosSQL estático 176

REDEFINES, cláusula de COBOL 128

registro especial CURRENT EXPLAIN

MODEefecto en SQL dinámico

vinculado 214

registro especial CURRENT PATHefecto en SQL dinámico

vinculado 214

registro especial CURRENT QUERY

OPTIMIZATIONefecto en SQL dinámico

vinculado 214

registros especialesCURRENT EXPLAIN MODE 214

CURRENT PATH 214

CURRENT QUERY

OPTIMIZATION 214

rendimientocláusula FOR UPDATE 188

liberación de bloqueos 181


SQL dinámico 22

resolución de problemasguías de aprendizaje 423

información en línea 423

restauraciónbibliotecas de rutinas externas 305

restriccionesCOBOL 28

en C/C++ 112

libdb2.so 271

rutinas 309

RESULT, variable predefinida de

REXX 143

RETURNS, cláusulaCREATE FUNCTION, sentencia 334

rutina SQLDB2, registro para REXX 145

rutina SQLDBS, registro para REXX 145

rutinasarchivos de creación 221

bibliotecas 301

C/C++archivo de inclusión 318


de función 329


conjuntos de resultados 326, 358

creación 362, 363, 371

crear 360

descripción 314

rutinas (continuación)C/C++ (continuación)

diseño 316

estilos de parámetros 319, 320

estructura sqludf_scrat 329


parámetros 319, 327


nulo 320


pase por referencia 326

pase por valor 326

rendimiento 307




soporte de tipo de datos xml 308


en 331


principal 356

clases 301

COBOLsoporte de tipo de datos xml 308

Common Language Runtimesoporte de tipo de datos xml 308

definición de la estructura del área

reutilizable 289

externasAPI y lenguajes de programación

soportados 290, 291

C/C++ 314, 316, 362, 363, 371

características 276, 277

conflictos de denominación 303

copia de seguridad y restauración

de archivos de bibliotecas y

clases 305

crear 297, 312

despliegue de bibliotecas y

clases 301


gestión de bibliotecas 305

modificación de archivos de

bibliotecas y clases 304

rendimiento 305

restricciones 277, 309

seguridad 303

sentencias prohibidas 309

soporte de 32 y 64 bits 306

soporte de tipo de datos xml 308

visión general 275

Javasoporte de tipo de datos xml 308

modificación 301


precompilador 356

portabilidad entre plataformas de 32 y

64 bits 289

restricciones 309

revinculación de bibliotecas

compartidas 387

sentencias prohibidas 309

sintaxis para pasar argumentos 342

UDF escalaresvisión general 278


principal 356

rutinas de lista de salidarestricciones de uso 194


API y lenguajes de programación

soportados 290, 291

archivos de bibliotecas y clasescopia de seguridad y

restauración 305


conflictos de denominación 303

crear 297, 312

despliegue de bibliotecas y

clases 301

gestión de bibliotecas 305

modificación de archivos de

bibliotecas y clases 304

rendimiento 305

seguridad de archivos de bibliotecas y

clases 303

soporte de 32 bits 306

soporte de 64 bits 306

visión general 275

SSAA1 LANGLEVEL, opción de

precompilación 60

SCRATCHPAD, opciónconservación del estado 285


(UDF) 285

Scripts de creaciónaplicaciones COBOL 246

Rutinas en C y C++ 225

sección de declaraciónC/C++ 90

COBOL 120

en C/C++ 89

en COBOL 120

FORTRAN 134

normas para sentencias 74

secciones críticas 36

secuencias de clasificaciónarchivos include

C/C 48

COBOL 50

FORTRAN 53

semáforos 36

sentencia COMMITasociación con cursor 181

sentencia CREATE ROUTINEPARAMETER STYLE clause 319

sentencia DECLARE CURSORdescripción 184

sentencia DESCRIBEproceso de sentencias arbitrarias 164

sentencia EXECUTEfinalidad 21

sentencia EXECUTE IMMEDIATEfinalidad 21

sentencia FETCHacceso repetido a datos 177

estructura de SQLDA 158

variables del lenguaje principal 152

sentencia INCLUDE SQLCAseudocódigo 56


sentencia INCLUDE SQLDAcreación de estructura de

SQLDA 159

sentencia ROLLBACKasociación con cursor 181

sentencia SELECTactualizar datos recuperados 180

asociación con sentencia

EXECUTE 21

declarar una SQLDA 153

descripción después de asignar

SQLDA 157

lista variable 165

recuperacióndatos una segunda vez 178

varias filas 180

sentencia DECLARE CURSOR 184

sentencia SET CURRENT

PACKAGESET 204, 220

sentencia WHENEVERmanejo de errores 57

sentenciasINCLUDE SQLCA 56

preparar con estructura de SQLDA

mínima 154

sentencias de SQLDinámico 15

Estático 15

guardar peticiones de usuario

final 166

manejadores de excepciones 194

manejadores de interrupciones 194

manejadores de señales 194

REXX 9

serializar ejecución 31

sintaxis en COBOL 7

sintaxis en FORTRAN 8

sintaxis en REXX 9

sintaxis para C/C++ 5

visualización de ayuda 419

señales de coherencia 208

servicios en tiempo de ejecuciónvarias hebras

efecto en enganches 31

short, tipo de datos de C/C++ 60

short int, tipo de datos de C/C++ 60

símbolossustituciones, restricciones del

lenguaje C/C++ 112

sintaxisdeclaraciones de indicador LOB,

REXX 147

incorporación de sentencias de SQLREXX 9

sección de declaraciónC/C++ 89

COBOL 120

FORTRAN 134

sentencias de SQL incorporadoC/C++ 5

COBOL 7

comentarios, C/C++ 5

comentarios, COBOL 7

comentarios, FORTRAN 8

comentarios, REXX 9

evitar división de línea 5

FORTRAN 8

sintaxis (continuación)sentencias de SQL incorporado

(continuación)sustitución de caracteres de

espacio en blanco 5

Solarisaplicaciones

opciones de compilación y enlace

en C 242


en C++ 244


enlace 261

rutinasopciones de compilación y enlace

en C 381


en C++ 382


enlace 393

solicitud de manuales de DB2 418

soporte de 32 bitsrutinas externas 306

soporte de 64 bitsrutinas externas 306

soporte de estructura de sistema principalC/C++ 114

COBOL 130

SQL, archivo de inclusiónaplicaciones C/C++ 48

aplicaciones COBOL 50


SQL (Structured Query Language)autorización

SQL incorporado 19

estilo de parámetros para rutinas

externas 298

SQL dinámicocomparación con SQL estático 22

consideraciones 22

cursores, programa de ejemplo 187

declarar SQLDA 153

definición 21

determinación de tipo de sentencia

arbitraria 164

efectos de DYNAMICRULES 211

finalidad 18

limitaciones 21

marcadores de parámetros 169

normas de sintaxis 21

PREPARE, sentencia 21, 152

proceso de cursor 185

proceso de cursores 159

rendimiento 18, 22

sentencia DESCRIBE 21, 152

sentencia EXECUTE 21

sentencia EXECUTE IMMEDIATE 21

sentencia FETCH 152

sentencias arbitrarias, proceso de 164

sentencias soportadas 21

suprimir filas 188

vinculación 214

SQL estáticoconsideraciones 22

SQL estático (continuación)declaración de variables del lenguaje

principal 76

finalidad 16

programa de cursor de ejemplo 186

recuperar datos 176

rendimiento 16

SQL dinámicocomparación 22

utilización de variables de sistema

principal 74

SQL incorporadoaplicaciones

migración 269

archivos de configuración de C++ de

AIX 230

Archivos de inclusión 47

archivos fuente 203

autorización 19

COBOL 7

comentariosC/C++ 5

COBOL 7

normas 8

comentarios en C/C++ 5

compiladores 12

DECLARE SECTION 4

Dinámico 20

diseño 42

entorno de desarrollo 12

Errores y avisos 150, 209

Estático 20

estructura de SQLCA 4

normasC/C++ 5

FORTRAN 8

Paquetes 219

planes de acceso 218

precompilador 209

programación 42

referencia a variables del lenguaje

principal 74, 84

rendimiento 25, 218

sentencias ejecutadas

dinámicamente 150

sentencias ejecutadas

estáticamente 150

sistemas operativos 12

Variables de entrada y salida 80

visión general 3

SQL-result, argumentofunciones de tabla 281

SQL-result-ind, argumentofunciones de tabla 281

SQL_WCHART_CONVERT, macro del

preprocesador 98

SQL1252A, archivo de inclusiónaplicaciones COBOL 50


SQL1252B, archivo de inclusiónaplicaciones COBOL 50


SQLADEF, archivo de inclusiónaplicaciones C/C++ 48

SQLAPREP, archivo de inclusiónaplicaciones C/C++ 48


Índice 437

SQLAPREP, archivo de inclusión

(continuación)aplicaciones FORTRAN 53

SQLCA, archivo de inclusiónaplicaciones C/C++ 48



SQLCA (área de comunicaciones de SQL)consideraciones sobre la utilización de

varias hebras 34

SQLCA, variable predefinida 143

SQLCA_92, archivo de inclusiónaplicaciones COBOL 50


SQLCA_92, estructura 53

SQLCA_CN, archivo de inclusión 53

SQLCA_CS, archivo de inclusión 53

SQLCLI, archivo de inclusión 48

SQLCLI1, archivo de inclusión 48

SQLCODEcampo, estructura de SQLCA 190

códigos de error 56

estructura 190

inclusión de SQLCA 56

SQLCODES, archivo de inclusiónaplicaciones C/C++ 48



SQLDArecuperar datos

programas de aplicación

REXX 175

SQLDA, archivo de inclusiónaplicaciones C/C++ 48



SQLDA (área de descriptores de SQL)consideraciones sobre la utilización de

varias hebras 34

SQLDACT, archivo de inclusión 53

SQLDB2, API de REXX 30, 173

sqldbchar, tipo de datosen rutinas C/C++ 334

selección 97

tipo de columna equivalente 60

SQLDBS, API de REXX 30

SQLE819A, archivo de inclusiónaplicaciones C/C++ 48



SQLE819B, archivo de inclusiónaplicaciones C/C++ 48



SQLE850A, archivo de inclusiónaplicaciones COBOL 50


SQLE850B, archivo de inclusiónaplicaciones COBOL 50






SQLE932A, archivo de inclusión

(continuación)aplicaciones FORTRAN 53




sqleAttachToCtx, API 31

SQLEAU, archivo de inclusiónaplicaciones C/C++ 48



sqleBeginCtx, API 31

sqleDetachFromCtx, API 31

sqleEndCtx, API 31

sqleGetCurrentCtx, API 31

sqleInterruptCtx, API 31

SQLENV, archivo de inclusiónaplicaciones C/C++ 48



sqleSetTypeCtx, API 31

SQLETSD, archivo de inclusión 50

SQLExceptionmanejo 191

SQLEXEC, API de REXXproceso de sentencias de SQL 9

registro 145

SQL incorporado 30

SQLEXT, archivo de inclusiónaplicaciones CLI 48

sqlint64, tipo de datos de C/C++ 60

SQLISL, variable predefinida 143

SQLJ (SQL incorporado para Java)archivos de creación 221

SQLJACB, archivo de inclusiónaplicaciones C/C++ 48

SQLMON, archivo de inclusiónaplicaciones COBOL 50


para aplicaciones C/C++ 48

SQLMONCT, archivo de inclusión 50

SQLMSG, variable predefinida 143

SQLRDAT, variable predefinida 143

SQLRIDA, variable predefinida 143

SQLRODA, variable predefinida 143

SQLSTATE, archivo de inclusiónaplicaciones C/C++ 48



SQLSYSTM, archivo de inclusión 48

SQLUDF, archivo de inclusiónaplicaciones C/C++ 48

rutinas C/C++ 318

SQLUTBCQ, archivo de inclusión 50

SQLUTBSQ, archivo de inclusión 50

SQLUTIL, archivo de inclusiónaplicaciones C/C++ 48



SQLUV, archivo de inclusiónaplicaciones C/C++ 48

SQLUVEND, archivo de inclusión 48

SQLXA, archivo de inclusiónaplicaciones C/C++ 48

Structured Query Language (SQL)dynamic

visión general 18

static 16

sucesos asíncronos 31

Ttablas

colocación del cursor al final 183

nombresresolver no calificados 220

recuperar filas, ejemplo 189

resolución de nombres no

calificados 220

tablas de indicadoresC/C++ 116

soporte de COBOL 132

términos y condicionesuso de publicaciones 424

TIME, parámetro 334

TIMESTAMP, parámetro 334

Tipo de datos BIGINTen SQL estático 77


(UDF)C/C++ 334

tipo de datos BIGINT de SQLC/C++, conversión 60

COBOL 67

FORTRAN 70

tipo de datos BLOBC/C++, conversión 60

COBOL 67

FORTRAN 70


(UDF)C/C++ 334

REXX 72

SQL estático 77

tipo de datos BLOB_FILE FORTRAN 70

tipo de datos BLOB FORTRAN 70

tipo de datos BLOB_LOCATOR

FORTRAN 70

tipo de datos CHARC/C++, conversión 60

COBOL 67

FORTRAN 70


(UDF)C/C++ 334

REXX 72


tipo de datos CHARACTER*n

FORTRAN 70

tipo de datos CLOB (character large

object)funciones definidas por el usuario

(UDF)C/C++ 334

tipo de datos CLOB_FILE FORTRAN 70

tipo de datos CLOB FORTRAN 70

tipo de datos CLOB_LOCATOR

FORTRAN 70

tipo de datos DATE 77

C/C++, conversión 60

COBOL 67


tipo de datos DATE (continuación)FORTRAN 70

REXX 72

tipo de datos DBCLOBC/C++, conversión 60

COBOL 67

en programas de SQL estático 77


(UDF)C/C++ 334

REXX 72

tipo de datos DECIMALC/C++, conversión 60

COBOL 67

en SQL estático 77

FORTRAN 70


(UDF)C/C++ 334

REXX 72

tipo de datos DOUBLE 77

C and C++ programs 60


(UDF)C/C++ 334

tipo de datos FLOAT 77


COBOL 67

FORTRAN 70


(UDF)C/C++ 334

REXX 72

tipo de datos FOR BIT DATAC/C++ 112

tipo de datos GRAPHICC/C++, conversión 60

COBOL 67

FORTRAN, no soportado 70

REXX 72

selección 97

tipo de datos INTEGER 77


COBOL 67

FORTRAN 70


(UDF)C/C++ 334

REXX 72

tipo de datos INTEGER*2 FORTRAN 70

tipo de datos INTEGER*4 FORTRAN 70

tipo de datos LONG VARCHARC/C++, conversión 60

COBOL 67


FORTRAN 70


(UDF)C/C++ 334

REXX 72

tipo de datos LONG VARGRAPHICC/C++, conversión 60

COBOL 67


FORTRAN 70

REXX 72

tipo de datos NUMERIC de SQLC/C++, conversión 60

COBOL 67

FORTRAN 70

REXX 72

tipo de datos REAL de SQLC/C++, conversión 60

COBOL 67

conversiónen rutinas C y C++ 334

FORTRAN 70

lista 77

REXX 72

tipo de datos SMALLINTC/C++, conversión 60

COBOL 67

FORTRAN 70


(UDF)C/C++ 334

REXX 72

sentencia CREATE TABLE 77

tipo de datos terminado en nulo de

C/C++ 60

tipo de datos TIMEC/C++, conversión 60

COBOL 67

en sentencia CREATE TABLE 77

FORTRAN 70

REXX 72

tipo de datos TIMESTAMPC/C++, conversión 60

COBOL 67

descripción 77

FORTRAN 70

REXX 72

tipo de datos VARCHARC/C++, conversión 60

C o C++ 112

COBOL 67

en columnas de tablas 77

formato estructurado, C/C++ 60

FORTRAN 70

REXX 72

tipo de datos VARGRAPHICC/C++, conversión 60

COBOL 67

FORTRAN 70


(UDF), C/C++C/C++ 334

lista 77

REXX 72

tipo de datos wchart 334

tipo de datos XML 308

tipo XML 80

tipos de datos 59

BINARYCOBOL 121

C/C++ 60


CLOB en C/C++ 112

COBOL 67

conversiónentre DB2 y COBOL 67

entre DB2 y FORTRAN 70

entre DB2 y REXX 72

tipos de datos (continuación)conversión entre DB2 y C/C++ 60

DATALINKvariable del lenguaje principal,

restricción 70

DECIMALFORTRAN 70

FOR BIT DATACOBOL 129

FOR BIT DATA en C/C++ 112

FORTRAN 70

lenguaje de sistema principal y

correspondencias en DB2 77

miembros de datos de clase, declarar

en C/C++ 108

puntero a, declarar en C/C++ 107

selección de tipos gráficos 97

soportados 77

COBOL, normas 67

FORTRAN, normas 70

temas sobre compatibilidad 77

VARCHAR en C/C++ 112

tipos de datos BINARYCOBOL 121

tipos de datos COMPCOBOL 121

tipos de datos COMP-1COBOL 67




tipos de datos de REXX 72

tipos de datos de SQLBIGINT 77

BLOB 77


CHAR 77

CLOB 77

COBOL 67

DATE 77

DBCLOB 77

DECIMAL 77

FLOAT 77

FORTRAN 70


(UDF)C/C++ 334

INTEGER 77

LONG VARCHAR 77

LONG VARGRAPHIC 77

REAL 77

REXX 72

SMALLINT 77

TIME 77

TIMESTAMP 77

VARCHAR 77

VARGRAPHIC 77

tipos de datos LOB (large object)declaraciones de datos en

C/C++ 103

declaraciones de localizador en

C/C++ 105

transferencia de datosactualización 180

Índice 439

truncamientovariables del lenguaje principal 81


UUDF (funciones definidas por el usuario)

de tabla 281

FINAL CALL 282

NO FINAL CALL 282

de tabla, modelo de proceso 282

escalares, FINAL CALL 280

portabilidad del área reutilizable entre

plataformas de 32 y 64 bits 289

unidades de trabajo (UOW)consideraciones sobre cursor 181

finalización, comportamiento del

cursor 181

UNIXaplicaciones C

creación 225

aplicaciones COBOL de Micro Focuscreación 248

rutinas Ccreación 365

rutinas COBOL de Micro Focuscreación 398

USAGE, cláusula en los tipos de

COBOL 67

Vvalor nulo, SQL

recepción por variable de

indicador 81

VARCHAR FOR BIT DATA, tipo de datosfunciones definidas por el usuario

(UDF), C/C++C/C++ 334

variablesREXX, predefinido 143

SQLCODE 92, 122, 135

SQLSTATE 92, 122, 135

variables del lenguaje principalCOBOL, tipos de datos 67

consideradas como globales por el

precompilador para un módulo en

C/C++ 88

declaraciónC/C++ 89

COBOL 120

como puntero a tipo de datos 107

con el generador de declaraciones

db2dclgn 77

FORTRAN 134

gráficas, COBOL 125

localizador de LOB, COBOL 127

normas 74

programas de SQL estático 76

utilización de sentencia de lista de

variables 165

declaraciones de datos LOBC/C++ 103

COBOL 126

FORTRAN 138

REXX 146


(continuación)declaraciones de localizadores de LOB

C/C++ 105

FORTRAN 139

REXX 147


archivosC/C++ 106

COBOL 128

FORTRAN 140

REXX 148

definición 74

denominaciónC/C++ 88

COBOL 119

FORTRAN 133

REXX 142

en sentencia de lenguaje de sistema

principal 74

en sentencia de SQL 74

en SQL dinámico 21

finalidad 86

gráficoC/C++ 96

FORTRAN 140

inicializar en C/C++ 112

LOB, borrar en REXX 149

miembros de datos de clase en

C/C++ 108


precompilador 98

referenciaC/C++ 86

FORTRAN 8

REXX 142

referencia desde SQL 74, 84

restricción de DATALINK 70

selección de tipos de datos

gráficos 97

series terminadas en nulo, manejo en

C/C++ 117

sintaxis para caracteres de longitud

fija, COBOL 123

SQL estático 74

truncamiento 81

variables del lenguaje principal de tipo

carácterfijas y terminadas en nulo de

C/C++ 94

FORTRAN 136


numéricasC/C++ 92

COBOL 122

FORTRAN 135

variables gráficas del lenguaje principalC/C++ 102

COBOL 125

rutinas 356

variables indicadorasdeclaración 81

durante INSERT o UPDATE 81

finalidad 81

FORTRAN 141

REXX 149

truncamiento 81

vinculaciónconsideraciones 216

diferir 217

opciones 214

programa de utilidad de descripción

de archivos de vinculación,

db2bfd 210

sentencias dinámicas 214

visión general 214

VinculaciónCreación de un paquete 198

Visual Basic. NETarchivos de proceso por lotes 221

Visual Explainguía de aprendizaje 423

volver a vinculardescripción 215

mandato REBIND PACKAGE 215

Wwchar_t, tipo de datos

selección 97

WCHARTYPE NOCONVERT, opción del

precompilador 356

Windowsaplicaciones C/C++

creación 227


enlace 245

aplicaciones COBOL de IBMcreación 249


enlace 263

aplicaciones COBOL de Micro Focuscreación 251


enlace 264

rutinas C/C++creación 367


enlace 384

rutinas COBOL de IBMcreación 399


enlace 395

rutinas COBOL de Micro Focuscreación 401


enlace 396

XXML

aplicaciones C/C++Ejecución de expresiones

XQuery 166

aplicaciones COBOLEjecución de expresiones

XQuery 166

codificación de datos 79

declaraciones 79

expresiones XQuery 30, 166

función XMLQUERY 30, 166

recuperación de datosaplicaciones C 85


XML (continuación)recuperación de datos (continuación)


tipo de datos 79

XQuery 79

Índice 441

Cómo ponerse en contacto con IBM

Para ponerse en contacto con IBM en su país o región, consulte IBM Directory of

Worldwide Contacts en el sitio http://www.ibm.com/planetwide

Para obtener más información sobre productos DB2, vaya a

http://www.ibm.com/software/data/db2/.



http://www.ibm.com/software/data/db2/udb/

��

SC11-3190-00

Spine information:

IBM

DB

2 DB

2 Ve

rsió

n 9

Desa

rrol

lo de

ap

licac

ione

s de

SQ

L in

corp

orad

o ��

�

db2a1z90

Documents