----- Original Message -----
Sent: Tuesday, April 05, 2005 8:51
PM
Subject: RE: Reingenieria de Programas
clasicos, por programas de 2 o 3 capas, en RPG y RPGLE.
Hola Fernando, si mas o menos esa es la idea
de nuestro problema.
Algunos compañeros habian implementado algo con
parametros formados por DS externas que se mapeaban con los archivos a
procesar.
Pero al usar una subfile tendria que leer de a n regsitros
por vez, y guardar cual es el ultimo registro leido.
Creo, me parece
haber leido algo, para usar SQLRPGLE y poder armar un Recordset desde una
consulta SQL embebida en un RPG.
Eso estaria interesante.
Bueno, te
cuento que puse un weblog en http://nicoweblog.blogspirit.com/ ahi
puedes encontrar una entrada llamada "
Programacion de Capas en
RPG/ILE",
y puse el link al "Libro Rojo" de donde saque las
ideas....
Bueno espero les sirva.
Nicolas
-----Original Message-----
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
On Behalf Of Fernando Pérez
Sent: Tuesday, April 05, 2005 11:52 AM
To:
[email protected]
Subject: Re: Reingenieria de Programas clasicos,
por programas de 2 o 3 capas, en RPG y RPGLE.
Hola, Nicolás. Antes
que nada, una pregunta: ¿Me podrías decir qué redBooks de Ibm has leido sobre
esta materia?. Yo solamente he encontrado uno que , aunque no
trataba directamente de esto, tenía un apartado que hacía referencia.
Y
ahora lo poco que puedo aportar: aquí, al empezar a trabajar con programas de
servicio, decidimos que para evitar tener abiertos los ficheros tanto en el
programa como en los programas de servicio, el acceso a los ficheros (chain,
setll, read/e,...) se haría vía funciones definidas en los programas de
servicio. De esta forma se minimiza el nº de veces que un mismo fichero se
abre a la vez.
Por ejemplo, si un programa usa X programas de servicio
y tanto el programa como los programas de servicio han de usar el fichero Y,
en vez de que cada uno acceda directamente al fichero, tenemos un programa de
servicio con las funciones para chain, reade, .... del fichero Y, y de este
modo dicho fichero solo está abierto una vez y el programa y el resto de
programas de servicio acceden a él mediante las funciones.
No todos los
accesos a fichero se sirven mediante funciones. Por ejemplo, si un programa
carga un subfichero mediante un lógico que no es necesario en ningún programa
de servicio (ni se estima que lo pueda ser), el programa accede directamente a
dicho lógico.
Hablando del coste de esto: al principio te lías a sacar
las funciones de acceso a datos que vas necesitando y eso te consume tiempo,
pero hay que decir que la funcion para el chain, read, setll, ... de un
fichero a otro varía muy poco, y en poco tiempo salen como churros.
En
cuanto a las pantallas, no es que tengamos mucho en ese sentido. Yo trabajo
con un 'prototipo estándar de programa' que implementa el típico subfichero de
selección de acciones a realizar en sus registros. Mi meta es conseguir sacar
todas las funciones que pueda a un programa de servicio, pero seguiré teniendo
una pantalla y un programa por cada subfichero a mostrar.
A grandes
rasgos, es lo que tenemos por aquí, aunque se podrían escribir bastantes
páginas con los puntos a tener en cuenta y las decisiones a tomar. Es un tema
muy interesante, del que no se encuentra demasiada información. A ver que
podemos sacar en este hilo.
Nicolas Machado
escribió:
Hola,
queria consultar si alguien intento la faraonica
tarea de reconvertir
programas escritos en rpg, de la forma clasica, donde
los accesos a las
pantallas y los datos están en el mismo programa, al
nuevo paradigma de 2 o
tres capas.
He leido algunos RedBooks de Ibm,
pero los ejemplos son muy basicos.
Necesito tener una nocion mas real del
verdadero esfuerzo que implicaria
hacer unos cambios.
Nuestra
aplicaion esta desarrollada con muchas pantalas con Subfiles,
similares al
trabajar del PDM.
Que por suerte no tienen mucha logica ( de negocios )
dentro de dichos
programas.
Pero asi y todo tenemos alrededor del 1500
pantallas.
Si alguien me puede dar algo de vtra experiencia se los
agradecere.
Saludos
Nicolas
--
Saludos.
Fernando
Pérez
Cerámica Saloni. Dpto. Sistemas
--
No se han detectado virus en este correo
saliente.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database:
266.9.2 - Release Date: 05/04/2005
