Muchas gracias por tu respuesta Mariano, es sumamente interesante. Si decidimos ir hacia adelante, ten por seguro que me pondre en contacto con vosotros.
Joan Llobet P.D. Mi pesame a los familiares de las victimas de Madrid. NO a ETA > Hola, > > Nosotros tenemos nuestros desarrollos migrados a Caravel. Si me > concretasm�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 > funcionantodos. 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 > diferenciaentre 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�digosuperior 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�cterde 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 > soportadosmuchos, 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 > sistemaoperativo 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, > tienesque 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 > procesopara 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 > desarrollarvosotros. 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 > cuandotengas 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 > correspondientedriver 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 > siemprehay 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 > distintosservidores. > 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 > ficherosXML) �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. > Particularmeteno 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� > desarrollandouna 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 > planteaun 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 > tomandoel pelo porque pr�cticamente lo ver�n igual. Cierto es que > tecnol�gicamenteno 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 > vuestrasaplicaciones 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] > _____________________________________________________ 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]
