SUMARIO

Colaboraciones

Nuevos consejos tecnicos paramanejo de PTFs 2

Protegiendo los valores deseguridad del sistema 4

Utilizar DRDA para ejecutarsentencias SQL en otro iSeries 8

Copiar datos de DB2 remotamediante DB2 para i 7.1 11

Consulting

Cómo crear tablas de trabajoen la QTEMP y seleccionarla librería en el momentode ejecución 13

COLABORACIONES

Nuevos consejos técnicospara manejo de PTFs

Protegiendo los valores deseguridad del sistema

Utilizar DRDA para ejecutar sentencias SQL en otro iSeries

Información sobre Power Systems, incluidos AS/400, iSeries y System i

Año 26 - Agosto 2012 Nº 283 Precio: 7 Euros

Tras publicar mi artículo, “Cuatro simples reglas para la gestión de PTFs” del 21 de Marzo en ITJungle (http://www.itjungle.com/fhg/fhg032112-story03.html), recibí interesantes comentarios de nuestros lectores sobre las PTFs que he decidido añadirlo en este nuevo artículo. A continuación siguen nuevos consejos y técnicas sobre la gestión de PTFs que puede facilitar la aplicación de parches de PTF en sus máquinas IBM i.

Nuestro lector, Richard Shearwood, nos comentó lo siguiente sobre si IBM corregía los paquetes Cume PTF que con-tienen PTFs incorrectas una vez el paque-te ya ha sido publicado.

“ Que yo sepa, IBM nunca ha actua-lizado los paquetes Cume PTF con nue-vo contenido. Pero si que reemplazan las Cume PTF rápidamente si necesitan ha-cerlo.

Los diversos Valores del Sistema que vienen definidos en el IBM i constituyen la configuración principal del control del sistema que determinará como trabaja el sistema. Por citar algunos; el valor QCR-TAUT, indica que tipo de autorización *PUBLIC tendrán los nuevos objetos creados; el valor QALWOBJRST indi-ca si existe alguna restricción sobre los objetos que pueden ser restaurados en el sistema; y los valores QTIME y QDATE almacenan la fecha y hora actuales del sistema.

Cualquier usuario que, además de us-ted, tenga privilegios de oficial de seguri-dad o altos niveles de autorización puede cambiar la configuración almacenada en los Valores del Sistema. En un caso en concreto, un cambio poco recomendable en el valor del sistema QCRTAUT hizo que el sistema asignará las configuracio-nes de autorización incorrectas a los nue-vos objetos creados, dejándolos totalmen-te expuestos a su mala utilización.

Para empresas que utilicen SQL en múltiples máquinas o particiones lógicas, la DRDA (Distributed Relational Data-base Architecture) puede ayudar en las tareas de administración del SQL. Por ejemplo, con bastante frecuencia se de-sarrolla una rutina SQL en una máquina de pruebas y luego se duplica la rutina en una máquina de producción, lo que re-quiere un copiar y pegar del texto SQL u otro mecanismo para difundir la rutina. O en algunos casos, puede ser necesario sa-

ber que hay en un archivo del sistema de producción mientras se está trabajando en el sistema de pruebas, sin tener que iniciar otra sesión o utilizar el iSeries Navigator.

La arquitectura DRDA es de gran ayu-da en estos escenarios porque permite que un iSeries local ejecute sentencias SQL en un servidor remoto (esto incluye bases de datos DB2 ejecutadas en otras plata-formas, pero para simplificar solo consi-deraremos las que estén en un servidor iSeries).

Sigue en página 2

Sigue en página 4

Sigue en página 8

COLABORACIONES

Nuevos consejos técnicos para manejo de PTFs

Tras publicar mi artículo, “Cuatro simples reglas para la gestión de PTFs” del 21 de Marzo en ITJungle (http://www.itjungle.com/fhg/fhg032112-story03.html), recibí interesantes comentarios de nuestros lectores sobre las PTFs que he decidido añadirlo en este nuevo artículo. A continuación siguen nuevos consejos y técnicas sobre la gestión de PTFs que puede facilitar la aplicación de par-ches de PTF en sus máquinas IBM i.

Nuestro lector, Richard Shearwood, nos comentó lo siguiente sobre si IBM corregía los paquetes Cume PTF que contienen PTFs incorrectas una vez el paquete ya ha sido publicado.

“ Que yo sepa, IBM nunca ha actualizado los paquetes Cume PTF con nuevo contenido. Pero si que reemplazan las Cume PTF rápidamente si necesitan hacerlo. Hace tiempo que no lo veo, pero por allá en 2006, una Cume PTF tenía una PTF defectuosa que podía requerir volver a cargar el Licensed Internal Code (LIC) a eliminar. Así que la próxima versión después de esto salía 41 días des-pués. Los más curiosos pueden ver más detalles en

SF98088 (V5R3 defective PTFs) http://www-912.ibm.com/s_dir/sline003.NSF/3a8f58452f9800bc862562900059e09e/e41b3dfe1d7cb49b86256eac005dc242?OpenDocument .

Y hablando de paquetes de PTFs defectuosas, puede que yo haya tenido la mala suerte de encontrar un pro-blema en el último paquete acumulativo i 7.1, o incluso varios. Una o dos de las PTF claves tiene especificacio-nes CoReq/PreReq y el paquete no se aplica si el paque-te anterior es muy Viejo. En este caso, necesita aplicar la PTF 5770999 MF54291 como una *TEMP PTF con todas las PreReq PTFs y luego hacer lo mismo con la PTF 5770SS1 SI45000. Cambie sus atributos de IPL para que se haga la IPL en estado restringido con el siguien-te mandato CHGIPLA (Change IPL Attributes- Cambiar Atributos de IPL):

Haga la IPL de su máquina y cuando vuelva en estado restringido, vuelva a aplicar el paquete.”

¡Gracias Richard!, por esa valiosísima información sobre el problema del paquete acumulativo del i 7.1. Cir-cunstancias como la PTF defectuosa de su historia del 2006 son las que podrían producir un efecto perverso en

su sistema, y me llevaron a esta conclusión, no tenga pri-sa por aplicar las nuevas Cume PTF. Espere al menos un mes antes de aplicar una Cume PTF recientemente pu-blicada. Y asegúrese de comprobar en la página de IBM las PTFs defectuosas de la sección Preventive Service Planning (PSP) para saber lo último sobre como solventar los errores según la versión de OS. http://www-912.ibm.com/s_dir/sline003.nsf/ALLPSPBYREL

Las siguientes sugerencias de gestión de PTF vienen de un usuario de IBM. Algunas podrían ser consideradas como extensiones a mis 4 reglas de gestión de PTFs.

“El usuario iBM”“1. Haga una “foto” de la siguiente información clave

del sistema antes de cargar o aplicar una nueva PTF. Esto le dará un punto de retorno en caso de problemas con la PTF.

• Pantalla WRKSYSSTS (Work with System Status)• Pantalla WRKPTFGRP (Work with PTF Groups)• Valores del Sistema con el mandato WRKSYSVAL, “Work with System Values”• Los atributos de la IPL con el mandato DSPIPLA

2. Capture o salve la información básica de rendimien-to anterior a la aplicación de la PTF de modo que tenga datos con los que comparar si se produjeran problemas.

3. Desarrolle un plan de pruebas para ejercitar pro-fundamente las funciones de sistema y el código de sus aplicaciones de modo que las pruebas posteriores a la aplicación de las PTF hechas en el sistema de producción realmente prueben las PTF.”

“El rEdactor dE EstE artículo”.Existen buenas sugerencias para todo el mundo con

que minimizar cualquier efecto adverso derivado de la aplicación de un paquete Cume PTF en su sistema. En particular estos pasos pueden serle de utilidad si trabajan bajo un entorno Sarbanes-Oxley (SOX), donde puede que haya mayores exigencias para documentar las pruebas de PTF antes y después de aplicar una PTF. Puedo asegu-rarles que los requisitos en un entorno SOX son mucho más rigurosos para casos como aplicar PTFs. Seguir estos pasos podrían ayudar cuando los auditores se acerquen por sus instalaciones.

2 Agosto 2012ATTITUDES Nº 283

 CHGIPLA STRSTD(*YES)

 

COLABORACIONES

3 Agosto 2012ATTITUDES Nº 283

No piErda tiEMpo E iNstalE las HipEr ptF

Y también hubo esta sugerencia de Luis Rodríguez sobre la necesidad de precipitar las Hiper PTFs en su sis-tema.

“A la regla #2 No precipite las Cume PTF…quizás de mi artículo anterior, me gustaría añadir un apartado. Regla 2b) dese prisa con las Hiper PTFs, tras unas cuidadosas consideraciones. Las r\nHiper PTFs son de alto impacto/penetración en su sistema. Si comprueba la lista de Hiper PTFs y parece que alguna de ellas podría aplicarse en su sistema, no pierda el tiempo e instalelas cuanto antes.

Por lo que respecta a las Cume PTFs, soy uno de esos afortunados que nunca tuvo problemas con ellas. Aún así, la regla de esperar un mes antes de aplicar la última ver-sión publicada del paquete Cume PT, es buena.”

He tenido la misma experiencia que Luis, y entro en el club de los afortunados que nunca han tenido un problema con Cume PTFs defectuosas en mi sistema. Esperemos que ahora no se vuelva en mi contra. Dicho esto, todavía creo es conveniente esperar un mes para ver que pasa an-tes de aplicar el paquete.

Algo parecido a aquello de qué fue primero ¿el huevo o la gallina?, Ed Evers nos propone un pequeño rompe-

cabezas.

“Escuche hace ya un tiempo, que la manera más rápi-da de aplicar PTFs era:

Para sistemas ya existentes, aplique las group PTFs antes de aplicar las Cume.

Para nuevos sistemas, aplique las Cume primero y luego las group PTF.

¿Qué hay de cierto? Nunca he intentado aplicar las group PTF antes de un paquete Cume. Siempre aplico las PTFs cumulativas antes.”

Tengo que confesar que no tengo una respuesta para esta cuestión. Pensando en ello, no tengo claro por qué de-bería haber una diferencia en la aplicación/carga de PTFs según sean sistemas nuevos o viejos.

Mi instinto me dice que en cualquier caso, las Cume deberían ser cargadas antes de las group PTF. Normal-mente cargo tanto las Cume como las Group PTF a través de la opción 8 (Install program temporary fix package) del menu “Program Temporary Fix”(GO PTF). Si cambio el valor del parámetro “Prompt for Media” a “2=Multiple PTF volume sets”, la opción 8 me preguntará por las PTFs adicionales después de haber cargado el paquete Cume. Una vez cargadas las dos PTF, entonces les aplico al mis-mo tiempo una IPL.

COLABORACIONES

4 Agosto 2012ATTITUDES Nº 283

Los diversos Valores del Sistema que vienen defini-dos en el IBM i constituyen la configuración principal del control del sistema que determinará como trabaja el sis-tema. Por citar algunos; el valor QCRTAUT, indica que tipo de autorización *PUBLIC tendrán los nuevos objetos creados; el valor QALWOBJRST indica si existe alguna restricción sobre los objetos que pueden ser restaurados en el sistema; y los valores QTIME y QDATE almacenan la fecha y hora actuales del sistema.

Cualquier usuario que, además de usted, tenga privile-gios de oficial de seguridad o altos niveles de autorización puede cambiar la configuración almacenada en los Valo-res del Sistema. En un caso en concreto, un cambio poco recomendable en el valor del sistema QCRTAUT hizo que el sistema asignará las configuraciones de autorización incorrectas a los nuevos objetos creados, dejándolos total-mente expuestos a su mala utilización.

Con el fin de proteger el impacto de la modificación

de los valores del sistema relativos a seguridad, IBM pro-porciona un mecanismo de bloqueo/desbloqueo disponi-ble a través de las Herramientas de Servicio del Sistema (STRSST - System Service Tools). Para poder acceder a su configuración, el usuario debe tener acceso al usua-rio de las Herramientas de Servicio con ID de usuario y contraseña propios. Este perfil de usuario y su contraseña no son las mismas que las del operador del sistema. Son Usuarios de Herramientas de Servicio especiales como 11111111, 22222222 y como no, QSECOFR. Pero el ofi-cial de seguridad de las Herramientas de Servicio es un usuario distinto al perfil de usuario QSECOFR del opera-dor de sistema, que normalmente tendrá otra contraseña.

Para acceder a la función de Bloque/Desbloqueo de Valores del Sistema, introduzca el mandato STRSST (Start System Service Tools), introduzca QSECOFR como User ID y la contraseña del QSECOFR SST. Aparecerá el menú de Herramientas de Servicio del Sistema:

Protegiendo la modificación de los valores de seguridad del sistema

 

Nº ejemplares: 8.500Precio ejemplar: 7,00 euros (Anual 60 )Difusión: Andorra, Portugal, Italia y EspañaPublicidad: Tel. 93 319 17 23

Edita: American Top Tools, S.L.Via Laietana, 2008003 Barcelona

Tel. 93 319 16 12 - Fax 93 319 17 55E-mail: att@att.es

Depósito Legal: B-18.455-1993 Imprime Graficas AltagrafPublicación: 10 ediciones

Alcance: 00/28

COLABORACIONES

5 Agosto 2012ATTITUDES Nº 283

Al seleccionar en el menú la opción 7 - “Trabajar con seguridad del sistema” se muestra la siguiente pantalla.

 

Para bloquear la modificación de los valores del siste-ma relativos a seguridad introduzca la opción 2 en la op-ción “Permitir cambios seguridad valor sistema” y pulse Intro. La opción 2 evitará que nadie, incluído el QSECO-FR, pueda realizar cambios sobre los valores del sistema relativos a seguridad.

¿Qué ValorEs dEl sistEMa EstáN protEgidos dE ModiFicacioNEs?

Obviamente no es prudente restringir el cambio de to-dos valores de sistema a todos los usuarios. Una restric-ción total impediría que la fecha cambiara a medianoche y que la hora cambiase durante el día. El sistema también ajusta pools de memoria durante el día lo que causa cam-

COLABORACIONES

6 Agosto 2012ATTITUDES Nº 283

bios en valores del sistema relativos a la asignación de espacio de almacenamiento, como el QBASPOOL.

En la versión de IBM i 6.1 la función de Bloque/Des-bloqueo SST actúa sobre los siguientes valores del siste-ma.

 QALWJOBITP QCRTOBJAUD QPWDEXPWRN

QALWOBJRST QDEVRCYACN QPWDLMTAJC

QALWUSRDMN QDSCJOBITV QPWDLMTCHR

QAUDCTL QDSPSGNINF QPWDLMTREP

QAUDENACN QFRCCVNRST QPWDLVL

QAUDFRCLVL QINACTMSGQ QPWDMAXLEN

QAUDLVL QLMTDEVSSN QPWDMINLEN

QAUDLVL2 QLMTSECOFR QPWDPOSDIF

QAUTOCFG QMAXSGNACN QPWDRQDDGT  

QAUTORMT QMAXSIGN QPWDRQDDIF

QAUTOVRT QPWDCHGBLK QPWDRULES

QCRTAUT QPWDEXPITV QPWDVLDPGM

QRETSVRSEC QSCANFSCTL QSSLCSLCTL

QRMTSIGN QSECURITY QSSLPCL

QRMTSRVATR QSHRMEMCTL QUSEADPAUT

QSCANFS QSSLCSL QVFYOBJRST

 

Si necesita restringir modificaciones sobre otros valo-res del sistema distintos a estos, puede intentar limitar el acceso al mandato CHGSYSVAL. Pero si los técnicos tie-nen altos niveles de autorización la restricción del uso del mandato CHGSYSVAL no será muy efectiva impidiendo

la modificación de los valores del sistema de la lista an-terior.

Definitivamente recomiendo establecer el Bloqueo de Seguridad de los valores del sistema de las herramientas de servicio del sistema. Si un valor del sistema protegido

Valores del Sistema afectados por la función Bloqueo/Desbloqueo de SST en IBM i 6.1

COLABORACIONES

7 Agosto 2012ATTITUDES Nº 283

necesita ser modificado, sólo debería hacerse con el con-sentimiento de administrador del sistema. En ese caso, un desbloqueo temporal permitirá la modificación de dicho valor del sistema. Una vez cambiado, el administrador debe volver a establecer el bloqueo.

dEMasiadas coMplicacioNEsMuchos usuarios técnicos comentan que prefieren no

establecer el bloqueo SST de los valores del sistema pues podría añadir posiblemente un paso extra durante la ope-ración de restauración. Dado que el valor del sistema QA-LWOBJRST puede quedar bloqueado con el parámetro *NONE, cualquier programa que adopte la autorización o tenga otros atributos sensibles a la seguridad no podrá ser restaurado.

¡¡Esa es una de las razones principales por las que tener activo el bloqueo SST de valores del sistema!! No quiero que ningún programa que adopte autorizaciones o cualquier otro programa con atributos sensibles a la se-guridad sea restaurado en mi sistema sin que yo tenga conocimiento de ello. Establecer *NONE en el valor del sistema QALWOBJRST permite proteger su sistema de instalaciones de programas dudosas con problemas de in-

tegridad, que pueden provocar violaciones del entorno y que potencialmente puedan adoptar la autorización de un usuario tan potente como el QSECOFR.

Si necesita restablecer un programa que necesaria-mente adopta autorizaciones, caso bastante probable, sim-plemente siga estos pasos:

• Desbloquee el bloqueo SST• Establezca el valor del sistema QALWOBJRST en

*ALWPGMADP • Realice la restauración del programa• Restablezca el valor del sistema a QALWOBJRST en

*NONE• Active el bloqueo SST de nuevo.

*ALWPGMADP = Allow restore of Adopting Pro-grams (Permitir restaurar Adopción de Programas)

Desde un punto de vista operativo activar o desactivar el bloque SST no es tan trágico. Son tan solo unos segun-dos. Desde el punto de vista de la seguridad, bloquear los valores del sistema relativos a la seguridad si es impor-tante.

COLABORACIONES

8 Agosto 2012ATTITUDES Nº 283

Para empresas que utilicen SQL en múltiples máqui-nas o particiones lógicas, la DRDA (Distributed Relatio-nal Database Architecture) puede ayudar en las tareas de administración del SQL. Por ejemplo, con bastante fre-cuencia se desarrolla una rutina SQL en una máquina de pruebas y luego se duplica la rutina en una máquina de producción, lo que requiere un copiar y pegar del texto SQL u otro mecanismo para difundir la rutina. O en algu-nos casos, puede ser necesario saber que hay en un archivo del sistema de producción mientras se está trabajando en el sistema de pruebas, sin tener que iniciar otra sesión o utilizar el iSeries Navigator.

La arquitectura DRDA es de gran ayuda en estos es-cenarios porque permite que un iSeries local ejecute sen-tencias SQL en un servidor remoto (esto incluye bases de datos DB2 ejecutadas en otras plataformas, pero para sim-plificar solo consideraremos las que estén en un servidor iSeries). La arquitectura DRDA permite, por ejemplo, lan-

zar una sentencia CREATE FUNCTION o ver los resulta-dos de una sentencia SELECT en la máquina de produc-ción, desde las entrañas de su herramienta SQL favorita, tal vez STRSQL, de su máquina de pruebas.

coNFigurar drdaLa configuración es sencilla. Por simplicidad, asumiré

que ambos iSeries o particiones lógicas tienen habilitado el TCP/IP y que no existen firewalls de por medio. A modo de ejemplo, denominaremos las máquinas como LIVE (re-mota) y TEST (local) y configuraremos la de pruebas para que ejecute sentencias SQL en la máquina de producción.

coNFiguracióN dE la MáQuiNa liVE (rEMota)

En la máquina remota, el DRDA utiliza el servidor DDM (Distributed Data Management) para recibir y pro-cesar solicitudes SQL remotas. Puede verificar que el servidor DDM está funcionando probando si el trabajo

Utilizar DRDA para ejecutar sentencias SQL en otro iSeries

COLABORACIONES

9 Agosto 2012ATTITUDES Nº 283

QRWTSRVR está activo en el sistema con el mandato WRKJOB QRWTSRVR. Para iniciar este servidor, utilice el siguiente mandato:

STRTCPSVR SERVER(*DDM)

coNFigurar la MáQuiNa dE pruEBas tEst (local)

Debe añadir una entrada para el iSeries LIVE (remo-to) en el directorio de bases de datos relacionales de su sistema local. Esto puede realizarse mediante el mandato

WRKRDBDIRE (Work with RDB Directory Entry). Uti-lice la opción 1 para añadir una entrada para el sistema remoto. Existen tres valores a configurar según vemos en la pantalla mostrada:

Asignamos un nombre como base de datos relacional el cual utilizaremos en las sentencias SQL para hacer re-ferencia al iSeries remoto. La ubicación remota es el nom-bre del host o dirección del iSeries remoto de su entorno. En el campo Tipo, especifique el tipo de conexión. Selec-cione *IP.

Alternativamente, la entrada puede realizarse utilizando el mandato ADDRDBDIRE – (Add RDB Directory Entry).

 

 

 ADDRDBDIRE RDB(LIVE) RMTLOCNAME(LIVE.YOURCOMPANY.COM *IP)

TEXT(PRODUCTION) 

COLABORACIONES

10 Agosto 2012ATTITUDES Nº 283

utilizar drda En la máquina TEST, inicie mediante el mandato

STRSQL la herramienta de SQL interactiva. Por de-fecto la conexión se realizará contra la base de datos del servidor local. Utilice la sentencia CONNECT para

cambiar la conexión actual al servidor remoto. La sen-tencia CONNECT requiere el nombre especificado en la entrada RDB para el servidor remoto (LIVE) y el nombre de usuario y contraseña:

En este ejemplo, LIVE es el nombre del sistema remoto que se añadió al directorio RDB.Una vez conectado, todas las sentencias SQL posteriores se-

rán realizadas contra el servidor remoto hasta que la conexión sea modificada. Observe que no puede mezclar objetos de dife-rentes servidores. Por seguridad, puede utilizar una estructura del tipo nombre en tres partes, servidor/schema/objeto, en al-gunas sentencias SQL que hará que sólo se ejecute la sentencia cuando se conecte a un servidor específico:

Para pasar de la máquina LIVE a la máquina TEST durante la sesión SQL, utilice la sentencia SET CONNECTION:

Si en algún momento no sabe en qué sistema se encuentra simplemente escriba CONNECT:

O consulte el registro del Servidor actual:

Cuando haya finalizado con la conexión remota, lance la sentencia DISCONNECT:

Actualmente, trabajo en un entorno con una máqui-na de producción y otra de prueba donde solo la máqui-na de pruebas tiene el kit de desarrollo de SQL instala-do (STRSQL). Además, no estoy autorizado a utilizar el iSeries Navigator a menos que esté en las oficinas, lo cual no es muy habitual. Utilizar SQL en la máquina de

producción es pues complicado. Pero gracias al DRDA puedo, desde la máquina de pruebas, realizar consul-tas rápidas de los datos en la máquina de producción y lanzar fácilmente sentencias CREATE FUNCTION y CREATE PROCEDURE en su máquina de producción después de haberlas probado.

 /* connect to remote iSeries with user profile MIKE */ CONNECT TO LIVE USER MIKE USING 'password'

 /* This will only run when connected to the TEST box */

Update Test/DataLib/Orders

Set ShippedFlag='Y'

Where ShipDate=Current_Date 

 SET CONNECTION TEST SET CONNECTION LIVE

 CONNECT /* Muestra la session actual */

 Select Current_Server From SysIBM/SysDummy1

 DISCONNECT LIVE 

COLABORACIONES

11 Agosto 2012ATTITUDES Nº 283

El IBM DB2 para el sistema operativo i7.1 introdujo la posibilidad de consultar directamente una base de datos remota DB2 para i sin tener que invocar una sentencia CONNECT explícitamente. Consultar una tabla remota con una sentencia SQL es posible, pero no contempla las consultas muy habituales que solicitan datos remotos combinados con datos locales.

Hasta ahora DB2 para i no permitía las referencias a tablas de múltiples base de datos relacionales en una sola sentencia. Si bien una reciente actualización (i7.1 tech-nology refresh 4 update - http://db2fori.blogspot.com.es/2012/04/db2-wiki-refresher.html) permite utilizar las sentencias INSERT/SELECT para referirse a tablas de diferentes bases de datos relacionales DB2. Incluso si no trabaja todavía con i7.1 puede también realizar esta tarea.

Pongamos por ejemplo, que su compañía tiene dos máquinas IBM i (a.k.a., iSeries, System i, AS/400) con bases de datos relacionales llamadas QERP (ERP) y QINV (Inventory) y que estas máquinas necesitan com-partir datos del maestro de artículos. Anteriormente, po-día compartir datos mediante FTP, DDM o SQL embebido mediante DRDA, entre otras técnicas.

Esta nueva característica permite a un desarrollador escribir una simple sentencia INSERT/SELECT (a ejecu-tar en QERP) que puede consultar la base de datos rela-cional remota QINV y colocar el resultado en una tabla local en QERP. La ventaja es que tampoco se necesita una sentencia CONNECT.

Si un desarrollador tuviera que escribir una rutina de recuperación de datos en el sistema QERP, una posible sentencia para copiar los datos del maestro de artículos a una tabla QTEMP local, sería tan sencilla como esta:

Esta sentencia utiliza la convención de nomenclatura de tres nombres que incluye “nombre de la base de datos relacional / nombre de schema (biblioteca) / nombre de la tabla o vista”. Si utiliza la convención de nomenclatura

SQL, utilice un punto en lugar de la barra de división.

Existen una serie de ideas a tener en cuenta si utiliza la convención de nomenclatura SQL:

• Está técnica utiliza DRDA para comunicarse con la base de datos relacional remota y realiza un CONNECT implícito entre bambalinas. Por tanto la DRDA debería ser configurada adecuadamente. Si no está seguro de cómo configurar su máquina local y remota para comunicarse mediante DRDA, lea el artículo incluido en este ejemplar de ATTitudes “Utilizar DRDA para ejecutar sentencias SQL en otro iSeries”.

• El sistema local tiene que tener una entrada de base de datos relacional registrada del sistema remoto. En nues-tro caso, la máquina QERP tiene que tener una entrada en

Copiar datos de una base de datos DB2 remota mediante

DB2 para i 7.1

 INSERT INTO QTEMP/ITEM_MASTER SELECT *

FROM QINV/DEV/ITEM_MASTER IM

COLABORACIONES

12 Agosto 2012ATTITUDES Nº 283

el directorio de base de datos relacionales para la máquina QINV. Utilice el mandato ADDRDBDIRE - Añadir entra-da directorio RDB - para añadir una referencia a la base de datos relacional del sistema remoto o partición.

• En la actualidad, está técnica solo puede ser utilizada con una sentencia INSERT/SELECT donde el destino del INSERT está en el sistema local y todas las tablas de la sentencia SELECT se refieren a la misma base de datos relacional remota. Cualquier otra sentencia que haga refe-rencia a distintas bases de datos relacionales remotas de-volverá el error: “SQL0512 - Statement references objects in multiple databases”. Con suerte en un día no muy leja-no, los desarrolladores podrán hacer referencia a distintas bases de datos relacionales en otras sentencias DML SQL.

• Si no es enemigo de escribir código embebido SQL o un procedimiento almacenado SQL, otras sentencias SQL como UPDATE, SELECT, CREATE TABLE AS, entre otras, puede beneficiarse de esta característica, simple-mente escribiendo INSERT/SELECT desde una base de datos remoto a una tabla temporal. Una vez los datos estén en la tabla QTEMP, una nueva sentencia SQL como UP-DATE puede hacer uso de los datos temporales copiados del sistema remoto.

• Solo tiene que estar trabajando con el sistema opera-tivo i7.1 y la actualización Technology Refresh 4 el siste-ma “cliente” (local) para que esta característica funcione. El sistema remoto “servidor” de IBM i, puede estar en versiones anteriores de sistema operativo. Personalmente he verificado que funciona con el i6.1.

• Cuando se conecte a otros sistemas, recuerde que la sentencia SELECT se ejecutará en el sistema remoto. En

consecuencia, solo puede referirse a características SQL disponibles en el sistema remoto y según la versión de i/OS. Por ejemplo, cuando se conecta con una máquina con i6.1, no podrá utilizar las nuevas funciones incorporadas por el i7.1.

• Cuando haga referencia a rutinas remotas tales como funciones definidas por el usuario en la sentencia SE-LECT, incluya el nombre del schema si utiliza la nomen-clatura de convención SQL. Por ejemplo, INSERT INTO LOCAL_TABLE SELECT MYLIB.MYFUNCTION()

• Los registros especiales SYSTEM_USER y CU-RRENT_SERVER pueden ser utilizados para consultar los nombres de servidor remoto y de usuario remoto.

One more thing, if you're not on i7.1, there has always been a relatively easy way to do this type of INSERT lo-cal/SELECT remote on older systems. To do so, follow these steps:

Una cosa más, si no trabaja con i7.1, siempre ha exis-tido una relativamente sencilla manera de hacer este tipo de INSERT local/SELECT remote en sistemas anteriores. Siga estos pasos:

1. Compruebe que existe una entrada de base de datos remota configurada en el sistema local.

2. Introduzca la sentencia SELECT SQL para una con-sulta de base de datos remota en un miembro fuente. No emplee la nomenclatura de tres nombres.

3. Cree una consulta de gestión de consultas (QMQRY) de un miembro fuente mediante el mandato CRTQMQRY:

13 Agosto 2012ATTITUDES Nº 283

CONSULTING

Pregunta usuario:Tengo un programa RPG que crea tablas de trabajo en la QTEMP. Me gustaría poder seleccionar la

biblioteca en el momento de ejecución. Intenté utilizar una variable host para la biblioteca en el mandato CREATE TABLE, pero no funcionó. Utilizo la nomenclatura convencional del sistema. ¿Pueden ayudarme?

rEspuEsta attMe encantaría poder decir que CREATE TABLE permi-

tiría una variable host para el cualificador explicito, pero no puedo. Pero si puedo sugerir otras opciones.

1. Utilice SQL dinámico. Introduzca el nombre de bi-blioteca en el mandato SQL.

 D SqlCommand s 256a varying D WorkLib s 10a

/free

*inlr = *on;

SqlCommand = ('create table ' + %trim(WorkLib) +

'/SomeTable +

(OneFish char(3), +

TwoFish dec (5,0), +

RedFish char(1), +

BlueFish date)');

exec sql

execute immediate :SqlCommand;

14 Agosto 2012ATTITUDES Nº 283

2. Utilice el registro especial CURRENT SCHEMA con SQL dinámico. Observe que el mandato CREATE TABLE no inclu-ye un cualificador.

3. Cambie la biblioteca actual. Tenga en cuenta que el sistema no le permitirá establecer la biblioteca QTEMP como actual. Puede que quiera restablecerla antes de que termine el trabajo. Una porción del programa CL llamador:

Una porción del programa RPG llamdo:

 D SqlCommand s 256a varying D WorkLib s 10a

/free

*inlr = *on;

exec sql

set Current Schema = :WorkLib;

SqlCommand = ('create table SomeTable +

(OneFish char(3), +

TwoFish dec (5,0), +

RedFish char(1), +

BlueFish date)');

exec sql

execute immediate :SqlCommand; 

 dcl &CurLib *char 10

/* change the current library */

rtvjoba curlib(&CurLib)

chgcurlib SomeLib

/* do the work */

call rpgpgm

/* reset the current library */

if (&CurLib *eq *NONE) +

then( chgcurlib *CRTDFT)

else ( chgcurlib &CurLib)

 

 exec sql create table SomeTable

(OneFish char(3),

TwoFish dec (5,0),

RedFish char(1),

BlueFish date);

 

Agosto 2012

COLABORACIONES

15ATTITUDES Nº 283

Este mandato creará un objeto de la consulta de gestión de consultas que contendrá la definición SQL del miembro fuente.

4. Ejecute la consulta QMQRY contra el servidor remoto y vuelque el resultado localmente en un archi-vo de salida:

En general, IBM ha permitido a los desarrolladores dar un paso más adelante acercándose al sueño utópico de ser capaz de acceder y manipular datos pertenecien-tes a distintos y heterogéneos sistemas en una simple sentencia SQL.

En un próximo artículo, explorare un mecanismo que permite referenciar en una sola sentencia SQL SELECT distintas tablas de base de datos relacionales (solo DB2) entre sistemas locales y remotos.

 CRTQMQRY QMQRY(REMOTE_QRY)SRCFILE(SRCLIB/QQMQRYSRC) 

 STRQMQRY QMQRY(REMOTE_QRY) OUTPUT(*OUTFILE) OUTFILE(QTEMP/REMOTE_DTA) RDB(MYREMOTE) USER(MIKE) PASSWORD(T0@ST) 

http://www.att.es/producto/keymai.htm