Conference pamsrc::decmessageq

>1.	Only 2 Naming Agents per bus can be run - one is the primary and the
>	other is the backup.  If only 1 Naming Agent is run then there is
>	no need to have a shared file system (for the ligthweight namespace)?

  You are correct, if do not intend to run a backup name server then you can
have the namespace stored on private file system.


>2.	Therefore some (most) groups will not have a Naming Agent and must 
>	therefore refer to the Naming Agent on a remote group to resolve a name
>	reference?  Can routing be used instead of creating a cross-group
>	link to the group running the Naming Agent?

  Yes, all the global name lookup requests are funneled to the two known name
servers.  However, if you use a heavyweight namespace (i.e. DECdns) you can use
many name servers.  You do this buy assigning name servers to segments of a
particular bus.

  Yes, routing works with naming.


>3.	The documentation says that the "process level namespace" is located
>	within the application's process space.  Is this process namespace
>	(cache) in the MQ API or in the application code?
                                                            
  The process cache is managed by the MQ code within each process. 


>4.	The first time an application references a name (using pams_locate_q),
>	the queue address is cached within the process cache.  For subsequent
>	sends must the application use pams_locate_q to resolve the name
>	(automatically using the proces cache)?

  Yes, the MQ code caches all name translations, however, you can choose to
ignore the process cache and use only the group and bus level caches and
namespaces.  You do this by specifying a namespace list w/o a reference to the
process cache.


>5.	When the queue reference changes in the namespace (detected by Naming
>	Agent?) both the group-level and process-level caches are cleared.
>	Does the Naming Agent keep track of which group and applications have
>	referenced the name and informs them of the change?

  There is no automatic invalidating of caches.  The application must decide
when to go out to the namespace to cause an update to the inner caches. 
Expected triggers for this operation are delivery failures and UNAVAIL msgs.


Marty

re the last point:- 

"Expected triggers for this operation are delivery failures and UNAVAIL msgs."

Does this work with MRQ's as targets.

i.e. you always get a success sending to an MRQ (as long as you can reach it).
     & as you do not need to explicitly attach to an MRQ you will not be able
     to detect connect/disconnect.

thanks in advance,

Bob 

re .1 

">1.	Only 2 Naming Agents per bus can be run - one is the primary and the
>	other is the backup.  If only 1 Naming Agent is run then there is
>	no need to have a shared file system (for the ligthweight namespace)?

  You are correct, "

this is not correct is it? You can run more than 2 nameing agents on a bus. The
only restriction is that any group can only be configured to see 2.

Please clarify.


No answer to the the MRQ question yet???

Bob 

>>2.	Therefore some (most) groups will not have a Naming Agent and must 
>>	therefore refer to the Naming Agent on a remote group to resolve a name
>>	reference?  Can routing be used instead of creating a cross-group
>>	link to the group running the Naming Agent?
>
>  Yes, all the global name lookup requests are funneled to the two known name
>servers.  However, if you use a heavyweight namespace (i.e. DECdns) you can use
>many name servers.  You do this buy assigning name servers to segments of a
>particular bus.

When you say

	However, if you use a heavyweight namespace (i.e. DECdns) you can use
	many name servers.  You do this buy assigning name servers to segments
	of a particular bus.

is "name servers" refering to the DMQ Naming Agent or the DECdns name servers?

>>5.	When the queue reference changes in the namespace (detected by Naming
>>	Agent?) both the group-level and process-level caches are cleared.
>>	Does the Naming Agent keep track of which group and applications have
>>	referenced the name and informs them of the change?
>
>  There is no automatic invalidating of caches.  The application must decide
>when to go out to the namespace to cause an update to the inner caches. 
>Expected triggers for this operation are delivery failures and UNAVAIL msgs.

You might want to add this to the documentation - "How Caching and Binding
Work" was the page that led me to ask the question.

Jeremy.

>	However, if you use a heavyweight namespace (i.e. DECdns) you can use
>	many name servers.  You do this buy assigning name servers to segments
>	of a particular bus.

The number of naming agents is limited to 2 currently (the second one is seens
as a failover). However, this is from each group's viewpoint. So you can have 
more naming agents per bus, but each group can contact two of them. 

In the case of the MessageQ proprietary namespace implementation, if you want a 
global bus-wide namespace, naming agents must share the file system where the 
namespace resides. If you want disjoint namespace, you can arrange this also
if it makes sense to you.

For DECdns, you can have as many DECdns servers you want, it is irrelevant to 
us. However, each naming agent must run on the same host machine as one DEcdns
clerk of course. So a Unix or NT client knowing a Naming Agent on a VMS host
may therefore access DECdns named queues.

Still no answer to the old MRQ and global naming question in .2????

Bob

re: .2

>"Expected triggers for this operation are delivery failures and UNAVAIL msgs."

>Does this work with MRQ's as targets.

>i.e. you always get a success sending to an MRQ (as long as you can reach it).
>     & as you do not need to explicitly attach to an MRQ you will not be able
>     to detect connect/disconnect.

	  The story here isn't as clean as with the other queue types because
	currently you cannot configure an MRQ to be active on attach.
	The lack of a requirement for an explicit attach really has
	nothing to do with it.  Basicaly you have the following to work
	with:

		- unavail msgs and delivery failures to detect xgroup 
		  reachability problems

		- Use pams_bind_q to bind the MRQ address to a name in
		  bus namespace.  Then have clients always to do a bus
		  lookup of the name.

		- Request response timers

		- Once an initial request has been successfuly acknowledged
		  the process reading from the MRQ could respond with a 
		  source Q address of one it's single reader queues.  This 
		  will allow the client to post an avail on it.


	Marty

"The lack of a requirement for an explicit attach really has
	nothing to do with it." 

What does this mean?  No-one has asked for explicit attach for MRQ's. Or you
think it's not needed?...

re :- Basicaly you have the following to work with:

         - unavail msgs and delivery failures to detect xgroup 
           reachability problems

           Drawback - clients need to know where the target is in order
                      to understand the error type they will get. 

         - Use pams_bind_q to bind the MRQ address to a name in
           bus namespace.  Then have clients always to do a bus
           lookup of the name.

           Drawback - who clears it? The name server has no knowledge
                      of who is connected so you could easily get the
                      case where the bound queue exits and clears the
                      name service but there are other queues available 
                      to read from the MRQ?

         - Request response timers - does this mean trigger error on
                      a timeout message?
           Drawback - MRQ's are generally used for high availability, quick
                      response. Waiting for a timeout to detect errors 
                      is not ideal.

         - Once an initial request has been successfuly acknowledged
		  the process reading from the MRQ could respond with a 
		  source Q address of one it's single reader queues.  This 
		  will allow the client to post an avail on it.

           Drawback - Then the client is 'BOUND' to the instance on the
                  MRQ. Makes the client again relatively complex. 

Bottom line - If you do not tell people BEWARE of MRQ's and Global Naming
              they may fall into any of the pitfalls above. Most of the
              solutions you recommend involve the client (and server) having 
              intimate knowledge of the group/queue configuration. Unless you 
              make the name server smarter, and get a notactive/unattachedq
              message status from MRQ's this will continually trip people up.

Comments please,

Bob           

Although the drawback mentionned are vary valid, you have to reckon they
are mutually exclusive as all the scenarios offered by Marty.  They were
offered as possible options to satisfy different kinds of requirements.

For instance, if as you say MRQ is used for high availability,  then the
queue should be always up and running and therefore bound to the name.

On another hand,  the use of a secondary queue is necessary to establish
a continued dialogue (aka session)  with a specific server on a MRQ when
a context needs to be maintained accross messages.

In conclusion,  MRQ is powerful but its usage must be tuned according to
application needs.  I agree with you that a  "hints and tips on MessageQ 
usage"  guide would be very useful, for a larger scope that only MRQ and
naming. In fact we were thinking of providing such material.