RE: tRAER DATOS DE UN AS/400 A OTRO...(POR LAS NOCHES EN SOMETIDO).

[Juan Ram�n Garcia]

Title: tRAER DATOS DE UN AS/400 A OTRO...(POR LAS NOCHES EN SOMETIDO).

Hola Cristina:   A ver si me acuerdo de todo, que a mi edad ya me falla la memoria ;-)   Voy a suponer que cada delegaci�n se conecta con la central en Madrid pero no disponen de l�neas de comunicaciones entre ellas, la t�pica red en estrella, si tuvieras l�neas entre delegaciones habr�a que cambiar alguna cosilla.   Para simplificar los ejemplos s�lo utilizar� 3 equipos con los siguientes nombres: - Central en Madrid        MAD - Delegaci�n Valencia   VLC - Delegaci�n Bilbao        BIO   Parto de la base de que las comunicaciones son permanentes y v�a TCP/IP.   * Configuraci�n de la red: Mandato CHGNETA Par�metros    SYSNAME(nombre del sistema MAD, VLC, BIO)                         LCLNETID(APPN)                         LCLCPNAME(mismo valor que SYSNAME)                         LCLLOCNAME(mismo valor que SYSNAME)                         DFTMODE(normalmente es BLANK que viene por defecto pero puedes crear una modalidad personalizada si precisas muchas sesiones SNA concurrentes, de momento d�jalo como viene)                         NODETYPE(en las delegaciones *ENDNODE en la central *NETNODE)                         NETSERVER(*LCLNETID *ANY)                         ALWANYNET(*YES)                         NWSDOMAIN(mismo valor que SYSNAME)   * Crear los controladores APPC: En cada equipo debes crear un controlador para cada uno de los equipos con los que se conecta - Conexi�n Madrid/Valencia (en el AS de Madrid) CRTCTLAPPC CTLD(VLCCTL) LINKTYPE(*ANYNW) ONLINE(*YES) RMTNETID(*NETATR) RMTCPNAME(VLC) Idem con Bilbao cambiando los nombres - Conexi�n Valencia/Madrid (en el AS de Valencia) CRTCTLAPPC CTLD(MADCTL) LINKTYPE(*ANYNW) ONLINE(*YES) RMTNETID(*NETATR) RMTCPNAME(MAD) Idem Bilbao/Madrid   * Crear los dispositivos APPC: Hay que crear un dispositivo por cada sistema con el que queremos conectar. - Conexi�n Madrid/Valencia (en el AS de Madrid) CRTDEVAPPC DEVD(VLC) LOCADR(00) RMTLOCNAME(VLC) ONLINE(*NO) LCLLOCNAME(MAD) RMTNETID(*NETATR) CTL(VLCCTL) MODE(*NETATR) APPN(*YES) SNGSSN(*NO) Idem con Bilbao cambiando los nombres. - Conexi�n Valencia/Madrid (En el AS de Valencia) CRTDEVAPPC DEVD(MAD) LOCADR(00) RMTLOCNAME(MAD) ONLINE(*NO) LCLLOCNAME(VLC) RMTNETID(*NETATR) CTL(MADCTL) MODE(*NETATR) APPN(*YES) SNGSSN(*NO) Idem BIO/MAD - Conexi�n Valencia/Bilbao (en el AS de Valencia) CRTDEVAPPC DEVD(BIO) LOCADR(00) RMTLOCNAME(BIO) ONLINE(*NO) LCLLOCNAME(VLC) RMTNETID(*NETATR) CTL(MADCTL) MODE(*NETATR) APPN(*YES) SNGSSN(*NO) Idem BIO/VLC   * Crear entradas SNA para sistemas TCP/IP Mandato CFGTCP opci�n 10 (tablas de sistemas principales) A�adir en cada sistema (que ya estar� definido al existir comunicaciones TCP/IP) una nueva entrada de nombre para cada sistema remoto: - En Madrid: Para Valencia     VLC.APPN.SNA.IBM.COM Para Bilbao           BIO.APPN.SNA.IBM.COM y as� en el resto de delegaciones   * Configurar los servicios de distribuci�n: Mandato CFGDSTSRV **Primero configurar las colas de distribuci�n (Opci�n 1) Crear como m�nimo una cola de distribuci�n para cada sistema remoto, se pueden crear hasta 4 colas por cada sistema y nivel de servicio pero en la pr�ctica con una sola cola es suficiente. - Madrid/Valencia (en el AS de Madrid) Cola                                    VLCDSTQ Tipo de cola                        *SNADS Nombre ubicaci�n remota    VLC Modalidad                            *NETATR Id red remota                        *LOC Nombre ubicaci�n local       *LOC   En el resto exactamente igual cambiando VLC por lo que corresponda en cada caso.   ** Configurar las tablas de direccionamiento (opci�n 2) Crear en cada sistema una entrada para cada uno de los sistemas con los que vamos a comunicar: - Comunicaci�n Madrid/Valencia (en el AS de Madrid) Nombre sistema/Grupo                VLC    (grupo en blanco) El nombre de cola para los 4 servicios de distribuci�n ser� VLCDSTQ (la que hemos creado en el ejemplo anterior). - Comunicaci�n Valencia/Madrid (en el AS de Valencia) Nombre sistema/Grupo                MAD    (grupo en blanco) El nombre de cola para los 4 servicios de distribuci�n ser� MADDSTQ - Comunicaci�n Valencia/Bilbao (en el AS de Valencia)  Nombre sistema/Grupo                BIO    (grupo MAD) El nombre de cola para los 4 servicios de distribuci�n ser� BIODSTQ   La diferencia es que al no existir comunicaci�n directa entre Valencia y Bilbao los archivos se enviar�n primero al sistema MAD el cual los re-enviar� autom�ticamente al sistema BIO     * Crear usuarios en el directorio de distribuci�n del sistema: Mandato WRKDIRE (Nota debe ejecutarse con QSECOFR) No es necesario crear todos los usuarios de cada sistema en el resto de sistemas, conque existan los perfiles que vais a manejar para estos menesteres es suficiente (por ejemplo QSYSOPR, QPGMR, CRIS, etc), para el ejemplo s�lo voy a utilizar el usuario CRIS. - En el AS de Madrid: Comprobar que exista una entrada con Id. de usuario CRIS Direcci�n MAD, si no existe crearla con la opci�n 1: Id Usuario/Direcci�n                    CRIS        MAD Nombre/Grupo Sistema               MAD        (grupo en blanco) Perfil usuario                                CRIS Id de usuario de red                    CRIS        MAD   Crear una entrada por cada sistema al que vamos a enviar datos: Id Usuario/Direcci�n                    CRIS        VLC Nombre/Grupo Sistema              VLC        (grupo en blanco) Perfil usuario                                en blanco Id de usuario de red                    CRIS        VLC   - En el AS de Valencia: Comprobar que exista el usuario "local" (CRIS    VLC), si no existe hay que crearlo como en el ejemplo de Madrid   Crear una entrada por cada sistema al que vamos a enviar datos: Id Usuario/Direcci�n                    CRIS        MAD Nombre/Grupo Sistema              MAD        (grupo en blanco) Perfil usuario                                en blanco Id de usuario de red                    CRIS        MAD   Id Usuario/Direcci�n                    CRIS        BIO Nombre/Grupo Sistema              BIO            (grupo MAD) Perfil usuario                                en blanco Id de usuario de red                    CRIS        BIO   En esta entrada el nombre de grupo contiene el nombre del sistema que hace las veces de "centro de la estrella" y redirecciona las entradas de red hacia el sistema de destino.   Adem�s de crear los usuarios "normales" (CRIS, QSYSOPR, o cualquier otro) podemos aprovechar para crear las entradas del usuario QNETSPLF (tanto locales como remotas), esto nos permitir� m�s adelante crear colas de impresi�n remotas de forma que un documento generado en Valencia se imprima por una impresora de Bilbao de forma totalmente autom�tica.   ------------------------------------------------------------------------------------   Despu�s de todo este rollo (afortunadamente s�lo hay que configurarlo una vez ;-) ya podemos comenzar a intercambiar archivos entre todos nuestros sistemas.   Supongamos que queremos transferir el archivo CLIENTES de la biblioteca DATOS desde Valencia a Madrid (OJO, la transferencia siempre la inicia el sistema de origen a no ser que desde el de destino se someta un mandato remoto que la provoque, podr�amos verlo m�s adelante)   El usuario de red (CRIS, QSYSOPR, etc.) ejecuta en Valencia el mandato SNDNETF (enviar archivo de red) en el par�metro FILE especifica la biblioteca/archivo que queremos enviar (DATOS/CLIENTES) y en el par�metro TOUSRID el usuario y sistema de destino (CRIS MAD), al pulsar INTRO el sistema VLC comenzar� a enviar al sistema MAD el fichero a trav�s de la cola de distribuci�n MADDSTQ, podemos controlar el estado del env�o con el mandato WRKDSTQ que nos indicar� el % de progreso de env�o. Una vez recibido en Madrid el sistema notificar� autom�ticamente al usuario CRIS de Valencia que el usuario CRIS de Madrid ha recibido el archivo y a su vez notificar� al usuario CRIS de Madrid que el usuario CRIS de Valencia le ha enviado ese archivo. En Madrid el usuario CRIS ejecutar� el mandato WRKNETF (trabajar con archivos de red), con la opci�n 1 (RCVNETF) podr� recibir el archivo indicando a que biblioteca/archivo lo quiere enviar.   Esto sirve tambi�n para objetos que no sean ficheros (por ejemplo programas) basta con crear un archivo de salvar, salvar los objetos dentro de ese archivo y enviarlo con SNDNETF.   Si adem�s preparamos bibliotecas con archivos DDM podemos trabajar en local con los archivos de otro sistema, la �nica excepci�n es el QRY que no nos permitir� trabajar con archivos DDM pero lo podemos solucionar v�a SQL remoto. Para ello debemos crear las entradas de directorio de las bases de datos de cada sistema, con el mandato WRKRDBDIRE crearemos en cada m�quina una entrada para la base de datos local y una por cada base de datos remota cuyo nombre debe coincidir con el nombre local de la base de datos en ese sistema.   Todo de un golpe puede parecer un rollo complicad�simo pero una vez configurado el manejo es muy sencillo y puede automatizarse totalmente, bastar�a con programar un trabajo sometido en cada delegaci�n que, a determinada hora, env�e los ficheros a Madrid. Para que la recepci�n en Madrid tambi�n sea autom�tica puede crearse un programita que monitorice la cola de mensajes del usuario que los recibe (mejor que sea un usuario exclusivo para estos fines) y al detectar el mensaje de que ha recibido el archivo "tal" autom�ticamente haga el RCVNETF y el resto del proceso.   Tambi�n, si la informaci�n a transferir no es muy grande puedes utilizar DDM y hacer que un programa en Madrid tome los datos de los ficheros de las delegaciones, esta ser�a la opci�n m�s sencilla de implantar.   Hay muchas posibilidades, por suerte o por desgracia siempre he trabajado en empresas con varias delegaciones y he tenido que ingeni�rmelas como he podido. Tengo, por ejemplo, impresoras asociadas a colas remotas para imprimir en otros sistemas, bibliotecas enteras s�lo con archivos, �reas de datos y colas de datos remotas para acceder en local a datos de otra m�quina, programas que monitorizan colas de mensajes y toman acciones seg�n el tipo de mensaje, etc. etc.   Espero que todo este rollo que acabo de soltar te sirva para algo, si tienes cualquier otra duda me tienes a tu entera disposici�n :-)   Un saludo.   Juanra ----- Original Message ----- From: Cristina V�zquez Osorio To: '[EMAIL PROTECTED]' Sent: Thursday, October 03, 2002 1:09 PM Subject: RE: tRAER DATOS DE UN AS/400 A OTRO...(POR LAS NOCHES EN SOMETIDO). Gracias Juan Ram�n, yo tengo conexion a los as/400, via tcpip. Asi que creo que me puedo saltar los ptos. 1 y 2. Necesito que me expliques...Desde como a�adir usuarios hasta el final.(recuerda que son una primeriza en todo lo que concierne a trabajar en nativo). Gcs. Saludos.Cris.