> -----Mensaje original-----
> De:   Fernando Pérez [SMTP:[EMAIL PROTECTED]
> Enviado el:   miércoles, 21 de septiembre de 2005 19:36
> Para: [email protected]
> Asunto:       Re: Consulta sobre programas de servicio
> 
> 
>               Tenía entendido que un grupo de activación se mantenía
> "abierto"
>       hasta que se reclamaban recursos (RCLRSC). ¿Qué aspecto tiene ese
> programa
>       puente? Me imagino que usarás QCMDEXC o algo parecido para hacer la
> llamada
>       al programa a ejecutar.
>       
>         
> 
> El grupo de activación finaliza y libera recursos cuando lo hace el
> programa que lo ha creado (el que tiene dftactgrp(*new)). Quizá te
> refieres a grupos de activación con nombre fijo,  caso de programas con
> dftactgrp(QILE), por ejemplo. Creo que en este caso es como tu dices, pero
> no trabajamos con ellos y no estoy seguro.
> 
        Lo probaré con *NEW, porque sí, he usado grupos de activación con
nombre.
> 
> El programa puente es tan simple como esto: 
> 
> H dftactgrp(*no)       
> H actgrp(*new)         
> C     *ENTRY        PLIST                                         
> C                   PARM                    Programa         10   
> C                   Call      Programa                            
> 
> Si tuvieras que pasar parámetros y no siempre fueran los mismos, la cosa
> se complica, pero en nuestro caso el gestor de menús no pasa parámetros a
> los programas.
> 
        Yo si que tengo que pasar parámetros. Voy a estudiar como resolver
esta pega.

        Un saludo,

        Javier Mora
        Dpto. Informática
        Dialsur S.A.U.




>               Para que esto funcione, todos los programas han de tener
> grupo de
>               activación *CALLER (en contadas ocasiones, cuando es
> necesario, lo tienen
>               a *NEW y tampoco causa problemas, pero no suele darse el
> caso). Esto
>               implica que ningún programa ha de ejecutarse en el grupo de
> activación por
>               defecto. O sea, que todos los programas OPM se han de
> convertir a ILE (las
>               cl's también).
>               
>                   
> 
>               Esto puede ser un problema. Buscaré alguna solución
> intermedia.
>         
> 
> Tampoco los has de pasar todos a la vez, pero sí todos los programas
> llamados desde el punto de menú que estés desarrollando/modificando. Lo
> que pasa es que aquí puede darse el caso de programas OPM que no se acaban
> llamando desde este punto de menú pero que llaman a programas que sí, y
> que has convertido a ILE. Ahí la cosa se complica. La solución que damos
> es que el programa ILE llamado por uno OPM tenga actgrp(*new), o bien
> crear otro programa puente con actgrp(*new) . Es ineficiente, porque se
> duplican recursos, pero tenemos el consuelo de que es temporal ( o esa es
> la idea ;). Y tampoco te va a degradar demasiado el sistema, salvo que
> tengas un lío de llamadas OPM/no OPM descomunal ).
> 
> La regla mínima a seguir es que en la cadena de llamadas no se de que un
> programa OPM acabe llamando a uno ILE con actgrp(*caller) y que use
> programas de servicio. Lo que pasa es que ya puestos es más sencillo y
> seguro convertir todos los de la cadena de llamadas a ILE.
> 
> Personalmente, de haber podido, hubiera pasado todos los programas a ILE,
> pero aquí seguimos a medias. Total, el paso consite en procesar los
> fuentes OPM para quitar los posibles FREE que puedan haber tras los CALL,
> convertir los fuentes con cvtrpgsrc, y recompilar. Todo muy automatizable
> y sencillo. Pero ya se sabe, no hay tiempo para hacer las cosas bien.
> Siempre sale algo más urgente.
> 
> 
> -- 
> 
> Saludos.
> 
> Fernando Pérez  
> 
> Cerámica Saloni. Dpto. Sistemas
>  <<Archivo: fperez.vcf>> 

__________________________________________________
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 visita la siguente URL:
http://coyote.combios.es/mailman/listinfo/forum.help400

Responder a