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]
