J2EE está basado en java, pero no es
simplemente "java", es mucho mas.
Soy un RPGero que hace como casi 10
años me "amplié" con el J2EE con Webshere.
La familia RPG es insustituible. Ni
J2ee ni nada. Eso sí, tambien es cierto que casi nada tiene que ver el
J2EE de hace 10 años
con el de ahora. La productividad es
infinitamente mas alta. Las herramientas de hoy dia nos lo permiten.
Quien
sigue defendiendo que
estos entornos "modernos"
son lentos o improductivos, honestamente, que se lo haga mirar. O no
cuentan
con una buena herramienta o
como pasa en la malloria de los
casos
no hay conocimiento ni profesionalidad. Un compañero ha comentado el
perfil
de los desarrolladores
de hoy dia, y no estoy de acuerdo.
Hay
muy buenos profesionales en entornos J2EE, otra cosa es lo que pasa en
muchos casos:
te envian el tipico programador
junior,
que por conocer java ya sabe J2EE y ni idea tiene de lo que supone un
entorno
transaccional ni una
base de datos relacional SQL de gran
volumen (que es lo que nos aporta nuestro sistema).
E insisto, para mi J2EE no es un
sustitudo
de RPGLE, yo lo veo como un participante más que viene a salvar nuestro
sistema de toda la vida.
La pareja J2EE- System i forma
un tandem insuperable. Vuelve a colocar a nuestra plataforma en una
posicion lider y capaz de responder
con el mejor resultado posible a
cuantas
exigencias propongan al departamento de IT, como antaño. Ya no te
vienen
con que se vea "bonito" y no verde, si no
con integracion B2B a tiempo real,
transacciones
distribuidas, ... y un largo etc etc etc
Es complejo?? si hablamos de crear
entornos
como los que RPG nos tiene acostumbrados a pocos problemas y maxima
fiabilidad,
sí,que los es
(aunque cada vez mucho menos). Pero
a mi me encanta que sea complejo, pues como pofesional me da mucho mas
valor que dedicarme a un entorno
como por ej. PHP o .NET que hasta mi
hijo de 13 años se hace sus programas. Pero no nos engañemos, sea J2EE,
sea .NET, sea PHP... a la hora de
crear un aplicativo serio y
ambicioso,
se nos presentan los mismos paradigmas escojamos uno u otro
(transacciones,
seguridad, integración,
escalabilidad). Al final si nuestras
necesidades nos empiezan a exigir al final acabamos o en J2EE o en .NET.
En particular prefiero el J2EE pues
es el que mejor se integra con nuestra plataforma, y ademas dado
el caso si resulta que en la central deciden dejar
el System i e ir a Solaris.... por
costes,
bueno, pues aunque cambien les seguiré siendo un profesional igual
de válido.
En particular me costo poco el
cambio
pero tambien me ayudo el hecho de conocer los entornos de PC y que en
éstos
los lenguajes y tecnologias
cambian más rapidamente. En lo que
estuve
15 años con RPG, en el pc pase por basic, cobol, c, delphy, C++,
java.....
Esto lo comento por qu un problema
gordo
en nuestro entorno es que muchos profesionales les cuesta afrontar el
tremendo
reto de cambiar a J2EE o .NET.
Despues de pegarte 15 años con pocos
cambios (o al menos no muy radicales) el asumir un cambio de estos,
ciertamente
pesa como una losa. Yo lo hice por mi bien
en primer y porque siempre me supuso
un gran reto.
Y acabaré como comencé: RPG es
insustituible,
pero por sí solo no nos va a salvar la plataforma. En cambio ese rol sí
lo puede asumir J2EE Websphere y
así reforzar al System i, el mejor
del
mundo
Saludos
Luis López
Victor:
Me parece que lo que se esta
sugiriendo
es la interelacion entre RPG para el AS400 y el PHP para los sitios Web
internos o externos que corran los Objetos RPGF.
JOSE LUIS
De:
[email protected]
[mailto:[email protected]] En nombre de Dpto.Informática
Productos Climax(Jose Sánchez)
Enviado el: Miércoles, 20 de Enero de 2010 01:53 p.m.
Para: forum.help400
Asunto: RE: El RPGLE LLEGA A SU FINAL?
Pues….. en las
ultimas
semanas hemos realizado unos cursos de wdsc, algo de hats y webfacing
para
acabar “tocando por encima” algo de j2ee. Me considero un “repegero”
pero he tenido que reconocer que j2ee en el as400 es el futuro (por no
decir ya el presente). Creo que mis esfuerzos van a ir hacia ese
entorno
porque he visto flexibilidad, una rapidez de ejecución incomparable y
sobre
todo facilidad en la parte visual de la que tanto nos quejamos.
El cambio de “chip”
va a ser costoso mentalmente pero si queremos seguir “comiendo” de la
informática no hay mas remedio que dedicarse a ello.
Como anécdota, al
preguntar
al formador sobre php y zend nos comentó que ibm no “habla” de php sólo
de java. No entiendo entonces, si esto es así, el esfuerzo de Zend
para integrar en el os/400 el php, ¿alguien sabe que futuro tiene php
en
el as400?
Ojala ibm creara un
entorno
mas gráfico con el que poder seguir usando rpg. Ccreo que es lo único
que
nos falta en nuestro entorno y el rpg no moriría en aplicaciones de
negocio
o al menos conviviría con aplicaciones java.
Saludos de un
“repegero”
De:
[email protected]
[mailto:[email protected]] En nombre de Víctor
Bolaños
Enviado el: miércoles, 20 de enero de 2010 17:21
Para: forum.help400
Asunto: El RPGLE LLEGA A SU FINAL?
Me ha parecido conveniente "ree-publicar" este
comentario, no con el fin de sembrar temor, sino con el fin poner en
nuestras
cabezas los cambios por venir, No en cuanto a hardware AS400, I5, sino
en cuanto al nuevo desarrollo de software en nuestros equipos
Soy un hombre objeto
"El hombre objeto proviene de la instancia de
una
clase y de sus métodos." Esta provocadora frase que inicia una
reflexión escrita pensando en personas y empresas a las que aprecio, me
permite ser algo más radical y más coloquial en mis aseveraciones. Los
intereses dentro de este mercado son muchos y cada uno lleva su propia
mochila, pero la realidad es machacona y la podemos entender sin
comprometernos
con ella.
Desde aquel S/3 a fichas de 96 columnas, sin CHAIN
y sin
MOVEA, por decir algo que todos conocemos; o con su ciclo de control,
MR
y rupturas de nivel que sólo algunos conocen y que han quedado en
desuso,
han pasado "algunos" años. Nuestro ILE RPG brilla por la cantidad
de medallas que ha merecido. La cantidad de batallas que hemos ganado
con
tan poderosa herramienta y las que todavía podemos ganar... Perdonad mi
léxico pero tras ver la conmemoración del desembarco de Normandía,
nuestro
RPG, triunfante, me recuerda a muchos de los que por allí desfilaron;
orgullosos
y cargados sus pechos de medallas. Dicho esto, puedo afirmar sin
temor a equivocarme que al RPG se le acabó su ciclo. No que no
se mantenga, no que se quede sin soporte, no que no se necesite;
simplemente,
se acabó su ciclo. Largo, por cierto.
El sentido común y la mayor parte de la industria
ha decidido
invertir todos sus esfuerzos de investigación en un entorno que permita
que una aplicación pueda ser ejecutada, sin modificaciones, en
cualquier
plataforma. Un entorno que permita construir piezas para después
ensamblarlas
y que, si son más o menos estándar, se puedan reutilizar, dando lugar a
un mercado de componentes de software. Aquello que todos habíamos
deseado,
es posible: escrito una vez, escrito para siempre. Lo que nos da valor
como informáticos, nuestro pensamiento lógico, se multiplica por 10 o
por 100.
Toda la industria está de acuerdo. ¿Y nuestro
entorno,
lo está? ¿Y quienes formamos la industria que conoce y da soporte a la
mejor plataforma comercial jamás construida? Creo que sí, pero la
sensación
que me produce al hablar con unos y con otros es que se va a perder el
tren y que serán los técnicos de otras plataformas los que se comerán
el
pastel.
Una alternativa real
En nuestro entorno, JAVA es la única alternativa posible y nuestra
máquina,
si continua siendo, será una máquina para JAVA. ¿O es que hay otra que
nos pueda garantizar otros 30 años de mejoras continuas y una cobertura
a nivel mundial por parte de los fabricantes de software? No, no existe
otra alternativa consistente que no sea JAVA.
Las exigencias de nuestro entorno, respecto a
herramientas
y lenguajes, son las más restrictivas y exigentes del mercado, por eso
la mayoría sigue en la plataforma. JAVA ofrece ese nivel de calidad y
lo
sobrepasa. JAVA tiene sus herramientas, J2EE, WDS, EJB’s WAS, su
entorno,
igual que en el RPG, con el SDA, SEU, etc. No sólo instrucciones de
lenguaje
y su forma de resolver los problemas. JAVA resuelve los problemas de
otra
forma; una nueva forma de enfocar la solución tan consistente como con
el RPG. Una forma de resolver los problemas que las nuevas generaciones
de profesionales entienden perfectamente.
Un paralelismo insólito
El cambio va a ser como el dejar de fumar: primero hay que estar
convencido
de que se quiere dejar y luego hay que hacerlo. Es algo saludable y
necesario,
aunque la alternativa también existe. Se podrá fumar en los lavabos, en
las terrazas o en la calle, en pequeños grupos que miran a los demás
con
recelo. La apuesta segura es dejar de fumar, cuesta pero es lo que hay.
Se puede empezar poco a poco o de golpe, pero todo lo que se haga en
ese
sentido va en el camino adecuado.
JAVA es la apuesta segura, sin sucedáneos,
directamente
aire de la montaña, control total del entorno, sin intermediaciones,
sin "run times", sin convertidores ni traductores. Paso que das,
paso que avanzas.
Preguntas y respuestas
Y ahora una batería de preguntas que hace unos años me hice. ¿Cuánto
tiempo
tardará nuestro entorno en aceptar otro tipo de soluciones, un año,
tres...?
¿Cuánto tiempo tardarán los responsables y las direcciones de las
empresas,
en tomar posiciones ante una tendencia tan clara y diáfana de la
industria?
Los nuevos desarrollos requieren una nueva planificación y un nuevo
enfoque,
¿qué experiencia podremos aportar para plantearlo correctamente?
¿cuánto
tiempo podremos retrasarlo? Y si lo hacen otros ¿cómo sabremos que se
está
haciendo correctamente?
Hoy ya no me planteo estas preguntas. Hoy estoy
pensando
si voy a transformar los procesos Batch a JAVA o espero un año más, o
si
ampliamos nuestros servicios WEB, o si integramos un portal y un
WorkFlow.
Las ideas vuelven a fluir y me entusiasma el estar
en el
camino correcto. El nuevo I5 está en el mercado: más memoria y más
procesador
pensando en WAS y JAVA. Y en el modelo 520 algo de interactivo para
darnos
vidilla y algo más de tiempo; en el resto o todo o nada y el todo se
paga
caro.
Su turno. La toma de decisiones no se
puede
aplazar: o sálvese el que pueda o... A lo mejor no es para tanto,
también
nos puede tocar la lotería.
Juan Carlos Campo Aliagas, con más de 30
años de
experiencia en TI, es director general de Gabinete de Informática A.K.,
empresa de desarrollo de software.
From: alex martinez
<[email protected]>
To: forum.help400 <[email protected]>
Sent: Wed, January 20, 2010 7:18:25 AM
Subject: Re: Problema de rendimiento con campos Autonuméricos.
Hola:
Aún teniendo el último nivel de PTFs hay algunas no incluidas en
ninguna
lista.
Asegurate de tener instalada la SI36720 que afecta al módulo QSQRUN2 y
la función SQL_ValuesInto
¿ Cuando dices que no te adjudica CPU a que te refieres ? ¿A una demora
excesiva ? ¿Puede anotar en un log con timestamp los tiempos de
ejecución
de la sentencia SQL?
Salu2
El 19 de enero de 2010 19:04,
Manuel
Santos <[email protected]>
escribió:
Buenas.
Tengo un programa RPG en el cual recupero masivamente el último valor
autonumérico
de varias Tablas con lo siguiente:
C/EXEC SQL
C+
VALUES IDENTITY_VAL_LOCAL() INTO :IVAR
C/END-EXEC
Tengo la V6R1 actualizada al último nivel de PTFs al día de hoy.
No tiene nivel de compromiso.
Cuando ejecuto el programa no me adjudica CPU y creo que es por los
problemas
de bloqueo que produce.
La ejecución del programa es correcta, el problema es el rendimiento
por
falta de más CPU. He quitado la sentencia sustituyendo el código por
algo
parecido y el rendimiento me sube.
¿A alguien le ha ocurrido este problema?.
Saludos.
____________________________________________________
© Publicaciones Help400, S.L. - Todos los
derechos reservados http://www.help400.es
----------------------------------------------------
Para darte de baja visita la siguente URL:
http://listas.combios.es/mailman/listinfo/forum.help400
____________________________________________________
© Publicaciones Help400, S.L. - Todos los
derechos reservados http://www.help400.es
----------------------------------------------------
Para darte de baja visita la siguente URL:
http://listas.combios.es/mailman/listinfo/forum.help400
____________________________________________________
© Publicaciones Help400, S.L. - Todos los
derechos reservados http://www.help400.es
----------------------------------------------------
Para darte de baja visita la siguente URL:
http://listas.combios.es/mailman/listinfo/forum.help400