Hola Javier:

�y no te sirve que estos perfiles de usuario de reponedores utilizen
la misma cola de mensajes?

Crear una cola de mensajes gen�rica REPONEDOR
CRTMSGQ MSGQ(QUSRSYS/REPONEDOR) 

cambiar los perfiles de usuario de los reponedores para que utilizen
esta cola de mensajes,  por ejemplo:

CHGUSRPRF USRPRF(R1) MSGQ(QUSRSYS/REPONEDOR)  
CHGUSRPRF USRPRF(R2) MSGQ(QUSRSYS/REPONEDOR)  
CHGUSRPRF USRPRF(R3) MSGQ(QUSRSYS/REPONEDOR)  

Desde el/los programas que utilizan los preparadores, realizar un simple
SNDMSG TOMSGQ(REPONEDOR) 
cuando se den las condiciones 

�que opinas?

SAlu2
On 5/19/05, Javier Mora <[EMAIL PROTECTED]> wrote:
> Hola todos:
> 
>         Posiblemente el texto del asunto no sea muy clarificador pero no
> sab�a como expresarlo mejor. Os comento lo que quiero conseguir. �AVISO!,
> este mensaje puede ser largo, pero interesante.
> 
>         Tengo unos programas que gestionan trabajos complementarios de un
> almac�n de mercanc�a. Hay unos preparadores y unos reponedores; los primeros
> recogen mencanc�a de un "picking" (o servicio) y cuando se vac�a los
> reponedores sit�an en ese sitio un nuevo palet con mercanc�a.
> 
>         Actualmente cuando el preparador deja vacio el "picking" (hueco de
> donde recoge la mercanc�a), el programa cambia una serie de prioridades para
> avisar al reponedor de tal circunstancia, bajando el palet indicado. Esto
> funciona y lo hace bien.
>         El problema surge cuando cuando el reponedor adem�s hace otro tipo
> de trabajos y no est� pendiente (continuamente) de estos eventos. La idea es
> poder avisar, mendiante alg�n mecanismo, al reponedor est� haciedo lo que
> sea. La cosa se complica a�n m�s teniendo en cuenta que el mensaje se tiene
> que enviar a una persona en concreto (y que puede ser distinta a lo largo
> del d�a) y, adem�s, pueden haber varios reponedores y preparadores al
> tiempo.
>         No se si me he explicado bien.
> 
>         Mi soluci�n
> 
>         Realmente estoy barajando dos posibles soluciones: (1) usar el
> mecanismo de env�o mensajes del OS/400; (2) usar colas de datos.
> 
>         Necesito un mecanismo que sea capaz de:
>         - Identificar el reponedor concreto al que quiera enviar el mensaje
> (el preparador nunca sabe qui�n es y no necesita saberlo)
>         - Al reponedor le tiene que salir un "aviso" informando de lo
> sucedido,
> est� en el programa que �ste.
>         - Deber�a ser un sistema sencillo, ya que no quiero modificar la
> l�gica actual de los programas.
>         - Deber�a ser sencillo de mantener.
>         - No quiero tener que mantener en l�nea quien es quien, ya que puede
> ser muy variable y muy dif�cil de controlar.
> 
>         Solucion (1) - Mensajes
>                 Para mi es la m�s factible, es un sistema que gestiona el
> OS/400 y que permite controlar mensajes de ruptura mediante programas
> manejadores. Adem�s es una gesti�n por trabajo no por programa y es
> independiente del programa.
>                 �C�mo soluciono a qui�n env�o el mensaje? Mediante colas de
> mensajes distintas. El programa preparador env�a el mensaje a una cola
> concreta (que es variable en funci�n de distintos criterios) y el reponedor
> abre en "break" la cola en funci�n de los mismos criterios.
>                 Si hay varios reponedores en la misma "zona" s�lo uno ser�
> informado.
>                 Tengo que tocar muy pocos programas.
> 
>         Soluci�n (2) - Cola de datos
>                 Es una soluci�n m�s rebuscada.
>                 Me toca modificar todos los programas del reponedor para que
> consulte una cola de datos continuamente. Esto me obliga a cambiar
> programas.
>                 El destinatario es sencillo de resolver; puedo usar colas
> distintas o una cola con clave (que discrimina a qui�n va dirigido el
> mensaje).
> 
>         Mi consulta es la siguiente: �existe alg�n otro m�todo que me
> simplifica m�s el trabajo? Siento mucho el tama�o de esta consulta y
> entender� que no se me tenga muy en cuenta.
> 
> 
>         Un saludo a todos,
> 
>         Javier Mora
>         Dpto. Inform�tica
>         Dialsur S.A.U.
> 
> 
> __________________________________________________
> Forum.HELP400 es un servicio m�s de NEWS/400.
> (c) 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
>

__________________________________________________
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