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
