Hola, hola, hola. Aunque no est� interesado en Caravel, me he quedao envelesado leyendo este comentario.
Simplemente �genial!!!. Env�a mis m�s sinceras felicitaciones a tu compa�ero y muchas gracias a ti por proporcionarnoslo. Salu2. Cid Fern�ndez Sangrador e-correo:[EMAIL PROTECTED] En inform�tica no hay nada imposible... solo es cuesti�n de tiempo. -----Mensaje original----- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] En nombre de Mariano D�az Diaz Enviado el: mi�rcoles, 10 de marzo de 2004 11:58 Para: [EMAIL PROTECTED] Asunto: Re: Conversion RPG a JAVA Te mando la respuesta del compa�ero de miorganizacion encargado del proyecto de migrar nuestras aplicaciones utilizando Caravel, cualquier duda ya sabes. Saludos Mariano Diaz Hola, Nosotros tenemos nuestros desarrollos migrados a Caravel. Si me concretas m�s qu� es lo que quieres saber te contesto gustoso. Por si no tienes claro ni qu� preguntar, te hago un planteamiento y sobre �l decides. Supongo que lo primero es: �funciona?, la respuesta es: S�. En nuestro caso empezamos con esto hace 2 a�os. Migramos unos 11.000 objetos (entre PF, LF, RPG, DSPF, PRTF y CLP) y si bien, por el tama�o de lo que estabamos portando, la cosa se dilat� durantes algo m�s de un a�o, lo cierto es que ahora ellos est�n mucho m�s rodados y migran en plazos cortitos. Me gustar�a que te quedara claro que s�lo puedo hablar de los objetos que he puesto arriba. Me constan que tambi�n migran ILE (incluso COBOL), pero no era nuestro caso. En cuanto a otro tipo de objetos (QRYF, MNU, OVL, etc...): ni idea. En cuanto al proceso de migraci�n, todo depende de lo que uno se puede imaginar f�cilmente: * Que tengas todos los fuentes de los objetos a migrar. * Cuanto m�s limpio sea tu c�digo, menos riesgo de problemas * etc... S� quisiera mencionarte algunas cosas concretas: 1) Los GOTO. En Java esto no existe. Con Caravel te lo resuelven de la forma m�s elegante posible. Nosotros ten�amos variedad de casos y, si bien al principio hubo problemas con alg�n caso, lo cierto es que ahora funcionan todos. La soluci�n para integrar esto en el fuente java resultante ser� lo m�s raro de todo lo que vas a ver en el fuente migrado. 2) EBCDIC y ASCII: Esto no es una cuesti�n tribial. Si teneis intenci�n de usar una base de datos fuera del AS/400, debeis considerar que la diferencia entre estos dos tipos de c�digos puede afectaros. Ejemplo: En el AS/400, si hago un SETGT a una tabla para una clave alfanum�rica por *ALL'9', est claro que me he posicionado al final de la tabla (en EBCDIC s�lo los hay caracteres no imprimibles por encima del 9). Si esto mismo lo hago en ASCII, me he quedado a la mitad, pues todas las letras may�sculas tienen c�digo superior al 9 (ej.: 'A' es superior). En consecuencia, para llegar al �ltimo registro tendr�a que situarme por *ALL'Z'. As� pues, esto te afectar dependiendo si tienes en tu c�digo muchas cosas de este estilo. Ciertamente, para campos num�ricos este problema no existe y para campos alfanum�ricos se soluciona situ�ndose por *HIVAL (claro que *HIVAL no es m�s que el car�cter de mayor peso del sistema en que est�s trabajando y tanto en ASCII como en EBCDIC es algo no imprimible, por lo que la soluci�n es buena para Batch, pero mala para pantallas). 3) Comandos CL del sistema operativo. En este sentido tienen soportados muchos, pero no todos. Fundamentalmente lo que no tienen soportado es lo que no se debe tener soportado. Ej: CPYFRMTAP. �Por qu� no se debe tener soportado? porque estos comandos son excesivamente exclusivos del sistema operativo en el que est� trabajando (imaginas que tendr�a que hacer esto en p.e. Windows?) y Java es multiplataforma. TransTOOLs analizar� tu c�digo y te dir� qu� comandos concretos no se soportan. 4) Otra cosa, que al menos en nuestro caso, tiene su importancia es que tendr�s que decirle adi�s al mundo feliz del paso de ficheros de texto. Me explico. Imaginemos que tienes un proceso que lee los datos que te pasan en un fichero de registros de 250 posiciones (sin subdivisi�n de campos). Le llamaremos PEPE. Tu programa lee los registros de PEPE los corta en trozos y analiza cada parte para incorporar los datos a tu base de datos. Esto te permite que cualquiera que te quiera enviar un fichero para incorporar datos a tu sistema s�lo tiene que hacer un ftp y dejarte el chorizo de datos (de registros de longitud fija, 250 caracteres) como miembro del fichero PEPE. Vamos, que para cualquiera esto es mear en pared. Sin embargo, cuando est�s migrado, PEPE no ser� un simple archivo, sino que ser� una tabla de la base de datos. Como te puedes imaginar, para cargar datos en una tabla, tienes que hacer un Insert (comando SQL) o similar. Vamos, que ya no ser� tan tribial el que te pasen datos. Esto se soluciona bien cambiando tu proceso para que lea un fichero de texto plano (que se complica porque habr� que localizarlo dentro del sistema operativo en el que est�s trabajando), bien haciendote un proceso que pase el fichero de texto plano a tu tabla PEPE de la base de datos. Lo que est� claro es que eso lo tendreis que desarrollar vosotros. Obviamente, estoy hablando de bases de datos no DB2 UDB; si teneis intenci�n de seguir teniendo la base de datos en el AS/400, no tendr�s este problema (y tampoco lo del ASCII ;-). Groso modo, estos son los handicap m�s importantes con los que nos encontramos. Por otro lado est� el tema de la plataforma en la que trabajar�s cuando tengas tus aplicaciones migradas. No s� qu� es lo que sabeis sobre J2SE por lo que te pido disculpas tanto si me paso de explicaciones, como si me quedo corto y te suena a chino. 1) Tus aplicaciones migradas funcionar�n en Web. �Y eso qu� signfica? Pues que para ejecutarlas necesitar�s: un motor de base de datos, un driver JDBC para conectarse con la base de datos, un servidor de aplicaciones (todo esto del lado del servidor) y un navegador de Internet (esto del lado del cliente). 2) En cuanto al motor de base de datos, podr�s usar MS SQL Server, Oracle, DB2 UDB (la del AS/400) y Mutibase (TransTOOLs); con su correspondiente driver JDBC para conectarse. �Si se conecta por JDBC, podr�a conectarme a otra base de datos (p.ej. Sybase)?: NO. Para que eso funcionara no basta con que repliques la estructura de base de datos en el motor que quieras y te busques un driver para conectarse. Necesitar�s que TransTOOLs adapte su core para funcionar contra ese motor de base de datos. A d�a de hoy s�lo las mencionadas est� soportadas. 3) �Qu� es un servidor de aplicaciones? Software. Es la gracia de la arquitectura J2. Tu aplicaci�n migrada tendr� una serie de clases Java (Servlets y JavaBeans) y JSPs. El que se encarga de poner esto disponible en web es un software que se denomina "Servidor de Aplicaciones". No necesitar�s ninguno de alto nivel, funciona simplemente con un Tomcat. Tambi�n lo hemos probado con WebSphere y (nosotros a�n no lo hemos conseguido, pero s� que tienen alg�n caso funcionando, con WebLogic). Servidores de Aplicaciones hay muchos (iPlanet, JBoss, iAS, ...), y en teor�a (normas J2) tu aplicaci�n podr�a correr en cualquiera, pero siempre hay que hacer retoques en cosas relativas al despliegue; vamos que habr�a que currarselo para ver si funciona de verdad. Para ser justos, eso no es problema estrictamente de Caravel; tendr�as los mismos problemas si te hicieras una aplicacioncilla en J2 y trataras de desplegarla en distintos servidores. 4) En cuanto al navegador de internet, a d�a de hoy esto es innegociable. Tus estaciones cliente necesitar�n MS Internet Explorer. Olv�date del resto (Mozilla, NetScape, Opera, Gale�n, ...) porque no funcionar�n. Espero que en alg�n momento TT se decida a incluir alguno m�s, pero la cosa est complicada de momento. 5) Luego est� el tema del Sistema Operativo del Servidor (teniendo en mente que puedo tener una m�quina como servidor de base de datos y otra como servidor de aplicaciones o bien tener todo en la misma). Bueno, podr� ser MS Windows 2000 (o superior), Linux (lo he visto funcionar en Debian y en Red Hat), OS/400 (desde la 5.2, quiz� tambi�n desde la 5.1, pero te inchar�as a poner PTFs). Supuestamente, tambi�n UNIX (Solaris, HP UX, AIX, SCO, ...), pero esto ni lo he probado, ni lo he preguntado. Lo que est� claro es que el software de la base de datos y servidor de aplicaciones depender� del sistema operativo que vayas a usar. No hay de todo para todos. 6) Tambi�n quiero puntualizarte que a su favor cuentan con que al migrarte a Caravel, te llevas parte de la estructura de funcionamiento de un AS/400. Con esto quiero decir que se las han ingeniado para que sigas teniendo Colas de Trabajo, Colas de Salida, Descripciones de Trabajo, etc... pese a que obviamente son cosas que naturalmente no existen en p.ej. MS Windows. Eso, francamente, est� muy bien. Finalmente, te har� una reflexi�n sobre Caravel: Debeis tener claro que Caravel no es s�lo una forma de migrar. Tus aplicaciones resultantes de la migraci�n necesitar�n de Caravel siempre para funcionar. Esto implica que tendr�s siempre un archivo .jar que te dar TransTOOLs formando parte de tus aplicaciones. En ese .jar est� el core de Caravel (un conujunto de clases Java propiedad de TransTOOLs). Cuando abras un fuente migrado a Java, lo que ver�s ser� una clase con igual nombre que el fuente RPG o CLP de tu aplicaci�n original que extiende una clase Caravel. Detro de esa clase, todas las instrucciones originales son en realidad m�todos de la clase Caravel b�sica que est� extendiendo. (De los DSPF, PF, PRTF y LF no hablo porque en realidad se convierten en ficheros XML) �Pero es Java 100%? S�, �Si meto cualquier instrucci�n Java en un m�todo de la clase migrada funcionar�? S�. Ahora vienen las puntualizaciones: 1) Las clases Caravel que necesitas para funcionar est�n patentadas, por lo que tendr�s que pagar a TransTOOLs royalties. No imagines que una vez migrado, como ya estoy en Java y Java es gratuito se acaba la cosa. Digamos que tendr�s que retratarte para usar las clases de Caravel. Particularmete no me parece mal, pero a lo mejor no es lo que buscais. 2) Si sientas a dos personas (un programados RPG y un programador Java) delante de un fuente RPG migrado (que ser� un fichero .java), ten por seguro que entender� m�s lo que hace el programa el programador RPG que el de Java. A un programador RPG avispado, en un par de d�as le tienes escribiendo en "Caravel" (aunque no sepa muy bien qu� es lo que est� haciendo internamente). A un programador Java, pr�cticamente, le tendr�as que ense�ar a programar en RPG. 3) En cuanto a los DSPF y a los PRTF, como he mencionado, se convierten en ficheros XML. El XML es un lenguaje de marca (etiquetas). Cuando veas uno, lo entender�s todo, porque es pr�cticamente igual al fuente migrado (s�lo cambia la estructura). Lo que Caravel hace es generar el JSP (caso de las pantallas) a partir de ese XML. D�nde est� el problema. Pues que para desarrollar una nueva pantalla tienes que escribir el XML correspondiente y eso es tan duro como escribir un DSPF sin SDA. TransTOOLs est� desarrollando una herramienta para facilitar esto, pero no me consta que la tengan liberada (hace un m�s estaba en Beta). 4) A cualquier persona formada para trabajar en Java, cuando se le plantea un desarrollo orientado a objetos, se imagina objetos de negocio (clientes, proveedores, la facturaci�n, cosas as�). Obviamente Caravel no hace milagros. Tu aplicaci�n ser� Java, y por tanto estar� orientada a objetos, pero estos no ser� objetos de negocio. Digamos que m�s bien el objeto es el c�digo original (por eso tienes una clase Java para cada fuente migrado). Esto es lo m�s dif�cil de entender para un nativo Java (de hecho, ya me estoy arrepintiendo de haberlo mencionado porque para entender esto hace falta ver las cosas desde los dos lados, RPG y Java, e incharse a dar explicaciones). 5) Tambi�n est� la cuesti�n del aspecto de la aplicaci�n resultante. Por defecto, lo m�s probable es que tus usuarios piensen que les est�s tomando el pelo porque pr�cticamente lo ver�n igual. Cierto es que tecnol�gicamente no es ni parecido, pero expl�cale eso a quien s�lo quiere el rat�n y colorines. Una vez migrado, podr�s hacer cosas para cambiar el aspecto de las pantallas (TransTOOLs te echar� una mano, pues est�n de continuo desarrollando cosas para mejorar esto de manera autom�tica). En cuanto a los listados, no esperes milagros, tendr�n el mismo aspecto que cuando los sacabas por el AS/400 (si bien te incluyen una funcionalidad para verlos en HTML y otra para transformarlos a PDF). En f�n, que no quisiera aburrirte. En resumen, hasta donde yo s� las soluciones perfectas no existen. Si no estais muy puestos en J2 y/o no quereis dedicar un porr�n de horas a hacer reingenier�a para pasar vuestras aplicaciones a J2, Caravel es buena soluci�n. No puedo compar�rtelo con otras soluciones (espero que alguien del Foro pueda hablarte de otras formas de pasar a Java). Nosotros estamos contentos con el resultado (si bien todo en esta vida es mejorable). Lo que tenemos claro es que, en nuestro caso, no estar�amos donde estamos si hubi�ramos optado por otra soluci�n (ni en coste, ni en tiempo, ni en calidad del resultado). En cualquier caso, os recomiendo que vayais abriendo vuestra mente porque el mundo de arquitecturas web con J2 es infinitamente m�s complejo que nuestro entra�able RPG en AS/400. Saludos, Oscar I�igo. ----- Original Message ----- From: "JLLOBETG" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, March 09, 2004 12:54 PM Subject: Conversion RPG a JAVA > Hola, estamos estudiando la posibilidad de convertir todos los > programas RPG a JAVA. > > Se esta mirando la posibilidad de utilizar el producto CARAVEL de > TransTools. > > Alguien puede aportar informacion o experiencias al respecto. > > Gracias > > Joan Llobet > > > > > _____________________________________________________ > Forum.HELP400 es un servicio m�s de NEWS/400. > � Publicaciones Help400, S.L. - Todos los derechos reservados > http://www.help400.es > _____________________________________________________ > > Para darte de baja, env�a el mensaje resultante de pulsar > mailto:[EMAIL PROTECTED] > > _____________________________________________________ Forum.HELP400 es un servicio m�s de NEWS/400. � Publicaciones Help400, S.L. - Todos los derechos reservados http://www.help400.es _____________________________________________________ Para darte de baja, env�a el mensaje resultante de pulsar mailto:[EMAIL PROTECTED] _____________________________________________________ Forum.HELP400 es un servicio m�s de NEWS/400. � Publicaciones Help400, S.L. - Todos los derechos reservados http://www.help400.es _____________________________________________________ Para darte de baja, env�a el mensaje resultante de pulsar mailto:[EMAIL PROTECTED]
