Utilización del SQLJ incorporado con el controlador de herencia de DB2 for z/OS.
SQLJ (Structured Query Language in Java™) es un conjunto de extensiones de programación que permite al programador utilizar el lenguaje de programación Java para intercalar sentencias que proporcionan solicitudes de base de datos SQL (Structured Query Language). Puede utilizar el controlador de herencia DB2 para z/OS con las aplicaciones de acceso a datos.
Acerca de esta tarea
- Para utilizar SQLJ con WebSphere para z/OS y el controlador heredado de DB2 para z/OS, instale el APAR PQ76442 de DB2.
- El controlador de herencia de DB2 para z/OS da soporte a los beans CMP (persistencia controlada por contenedor) generados mediante SQLJ. Utilice el controlador de DB2 Universal para los CMP generados mediante SQLJ.
Los siguientes son los pasos necesarios para desarrollar aplicaciones con SQLJ que se ejecutan en WebSphere Application Server para z/OS versión 6.0 utilizando el controlador de herencia de DB2 para z/OS.
Procedimiento
- Diseñe la aplicación en Rational Application Developer según sus
requisitos, utilizando SQLJ cuando sea necesario. Por ejemplo, si desarrolla un bean llamado Prueba
que utiliza BMP, codifíquelo como PruebaBean.sqlj (en lugar de PruebaBean.java).
- En la instalación de DB2 para z/OS, copie el archivo db2sqljclasses.zip en un directorio de la estación de trabajo, a continuación, modifique la vía de acceso de creación Java del proyecto Java de EJB de modo que incluya db2sqljclasses.zip.
- Convierta el código SQLJ siguiendo los pasos siguientes:
- Localice el archivo SQLJ, luego utilice la modalidad ASCII para transferirlo por FTP a un HFS en el entorno z/OS.
- Utilice el mandato sqlj para traducir el código SQLJ a código Java. Se generan dos archivos,
uno con la extensión .java y otro con la extensión .ser.
sqlj -compile=false NOMBRE_ARCHIVO_SQLJ
- Utilice la modalidad ASCII para transferir el archivo .java y la modalidad BINARIO para transferir el archivo .ser otra vez al directorio de la estación de trabajo donde reside el archivo SQLJ.
- Renueve el proyecto.
- Genere el código de despliegue para la aplicación.
- Exporte el archivo EAR.
- Instale la aplicación.
- Cree un origen de datos con el proveedor JDBC de DB2 para z/OS local (RRS). Cuando defina el proveedor de JDBC y origen de datos, los valores predeterminados son suficientes para proporcionar el soporte SQLJ.
- Instale la aplicación en WebSphere Application Server.
Utilice el origen de datos que ha creado en el paso 1 para resolver las referencias de recursos.
- Personalice los perfiles serializados Cuando genera el
código de despliegue, se crean los perfiles serializados o archivos con extensión .ser, que
son específicos de su aplicación. Estos perfiles deben personalizarse en entornos z/OS antes de
que se puedan utilizar.
- Utilice la transferencia binaria para transferir los perfiles serializados al entorno z/OS en que haya instalado la aplicación. También puede utilizar el mandato jar de Java para extraer los perfiles serializados del archivo JAR de EJB en el directorio EAR instalado.
- Utilice el mandato db2profc para personalizar los perfiles serializados. Puede obtener información sobre las diversas opciones asociadas con este
mandato desde la documentación de DB2; no obstante, aquí figuran los
requisitos mínimos para personalizar el perfil:
db2profc -pgmname=NOMBRE_PROGRAMA NOMBRE_PERFIL
- Donde:
- NOMBRE_PROGRAMA debe ser un nombre de miembro PDS de MVS válido y puede tener un máximo de siete caracteres:
- NOMBRE_PERFIL es el nombre del perfil serializado que desee personalizar. Debe ejecutar db2profc una vez para cada perfil.
- El programa de personalización de perfiles crea cuatro conjuntos de datos DBRM en NOMBREUSUARIO.DBRMLIB.DATA. de PDS. Los nombres de miembros de los DBRM empiezan por lo que especificó como NOMBRE_PROGRAMA.
- Asegúrese de que la variable de entorno CLASSPATH:
- La ubicación del perfil serializado
- El archivo JAR de EJB del directorio EAR instalado
- Asigna a un PDS para que contenga los DBRM que se crean. Déle el
nombre a este PDS de NOMBREUSUARIO.DBRMLIB.DATA, donde
NOMBREUSUARIO es el usuario que implementará el mandato db2profc.A continuación se muestra un ejemplo de campos:
Space units=TRACK Primary quantity=15 Secondary quantity=5 Directory blocks=10 Record format=FB Record length=80 Block size=27920 Data set name type=PDS
- Donde:
- Coloque los perfiles serializados existentes, que ahora están
personalizados, en una ubicación que forme parte de la classpath de la aplicación
y que esté antes que los perfiles serializados que existen en el
archivo JAR de EJB.
La salida del programa de personalización de perfiles de DB2 y el archivo de entrada tienen el mismo nombre. Mueva el archivo de salida por delante del perfil serializado original en la classpath. Alternativamente, puede mover el perfil personalizado al archivo JAR de EJB, sustituyendo el original. Se recomienda que sustituya el archivo original.
IMPORTANTE: si ejecuta el mandato db2profc desde el directorio donde existe el perfil serializado, el programa de personalización de perfiles sobrescribe el perfil serializado. Como sólo necesita la versión personalizada después de que se haya ejecutado el programa de personalización de perfiles, esto no representa normalmente ningún problema.
- Enlace los DBRM en un paquete. Nota: Debe crear las tablas de base de datos antes de enlazar los DBRM. Si no lo hace, el trabajo de enlace fallará.
El mandato de personalización db2profc crea una serie de los DBRM que deben estar enlazados a paquetes. Para cada perfil personalizado, se crean cuatro DBRM.
Estos DBRM:- Están ubicados en NOMBREUSUARIO.DBRMLIB.DATA
- Todos tienen nombres que empiezan por lo que ha especificado como NOMBRE_PROGRAMA
- Se enumeran de 1 hasta 4
Por ejemplo, si inicia la sesión como IBMUSER y especifica -pgmname=TESTBMP y luego ejecuta el mandato db2profc, se crean cuatro conjuntos de datos, TESTBMP1, TESTBMP2, TESTBMP3 y TESTBMP4 que se colocan en IBMUSER.DBRMLIB.DATA del PDS.
Estos conjuntos de datos deben estar enlazados a paquetes con el aislamiento de UR, CS, RS y RR. Debe ejecutar un enlace para todos los perfiles serializados que personalice.
- Después de enlazar todos los DBRM a paquetes, enlace los paquetes a un plan. Denomine el plan como desee.
IMPORTANTE: Debe incluir también los paquetes JDBC en la lista de paquetes (PKLIST) del nuevo plan. Los nombres predeterminados de los paquetes JDBC que se han de incluir son DSNJDBC.DSNJDBC1, ..., DSNJDBC.DSNJDBC4. Si la instalación no ha utilizado los nombres predeterminados para los paquetes JDBC, póngase en contacto con el administrador de DB2 para determinar los nombres de los paquetes JDBC que necesita incluir.
A continuación aparece un trabajo de ejemplo utilizado para enlazar un nuevo plan.- Se ha creado un perfil serializado, mientras estaba conectado como IBMUSER.
- Se ha especificado -pgmname=TESTBMP para ejecutar db2profc.
- El nombre del nuevo plan es SQLJPLAN.
//BBOOLS JOB (516B,1025),'IBMUSER',MSGCLASS=H,CLASS=A,PRTY=14, // NOTIFY=&SYSUID,TIME=1440,USER=IBMUSER,PASSWORD=IBMUSER, // MSGLEVEL=(1,1) //******************************************************************** //BINDOLS EXEC PGM=IKJEFT01,DYNAMNBR=20 //DBRMLIB DD DSN=IBMUSER.DBRMLIB.DATA,DISP=SHR //* DD DSN=MVSDSOM.DB2710.SDSNDBRM,DISP=SHR //SYSTSPRT DD SYSOUT=* //SYSPRINT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSTSIN DD * DSN SYSTEM(DB2) BIND - PACKAGE(TESTBMP) - QUALIFIER(IBMUSER) - MEMBER(TESTBMP1) - VALIDATE(BIND) - ISOLATION(UR) - SQLERROR(NOPACKAGE) - BIND - PACKAGE(TESTBMP) - QUALIFIER(IBMUSER) - MEMBER(TESTBMP2) - VALIDATE(BIND) - ISOLATION(CS) - SQLERROR(NOPACKAGE) - BIND - PACKAGE(TESTBMP) - QUALIFIER(IBMUSER) - MEMBER(TESTBMP3) - VALIDATE(BIND) - ISOLATION(RS) - SQLERROR(NOPACKAGE) - BIND - PACKAGE(TESTBMP) - QUALIFIER(IBMUSER) - MEMBER(TESTBMP4) - VALIDATE(BIND) - ISOLATION(RR) - SQLERROR(NOPACKAGE) - BIND PLAN(SQLJPLAN) - QUALIFIER(IBMUSER) - PKLIST(TESTBMP.* - DSNJDBC.* ) - ACTION(REPLACE) RETAIN - VALIDATE(BIND) END /*
- Otorgue la autoridad correspondiente a su plan nuevo. Utilice una interfaz DB2, como por
ejemplo SPUFI, para otorgar la autoridad. Emita este mandato:
Donde:GRANT EXECUTE ON PLAN NOMBREPLAN TO IDSERVIDORAPLIC
- NOMBREPLAN es el nombre del plan que ha enlazado.
- IDSERVIDORAPLIC es el ID bajo el que se ejecuta WebSphere; por ejemplo, CBSYMSR1.
- Configure el origen de datos para que utilice el nuevo plan
- En la consola administrativa de WebSphere Application Server para z/OS, vaya a Origen de datos y seleccione Propiedades personalizadas.
- Seleccione la propiedad personalizada planName.
- Actualice el valor de planName por el nombre que ha asignado al plan cuando lo ha enlazado.
- Establezca enableSQLJ en true.
- Detenga y reinicie el servidor.
- Ejecute la aplicación.


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tdat_sqljdb2zos
File name: tdat_sqljdb2zos.html