[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference pamsrc::decmessageq

Title:	NAS Message Queuing Bus
Notice:	KITS/DOC, see 4.*; Entering QARs, see 9.1; Register in 10
Moderator:	PAMSRC::MARCUSEN

Created:	Wed Feb 27 1991
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	2898
Total number of notes:	12363

2785.0. "Dynamic Addressing" by NWD002::GUNDERSON_RO () Mon Feb 24 1997 19:59

DMQ V4.0
Digital UNIX 4.0b
OpenVMS V6.2

I have a question regarding pams_bind_q() and pams_locate_q() for 
dynamically determining the queue address of a server (bus wide).  I
believe the 4.0 docs refer to this as "lightweight naming":

Psuedo-code:

SERVER:   pams_attach_q()
          pams_bind_q()  //bind the addres using an alias 
          do{
             pams_get_msgw()
             :
          }


CLIENT:  (in different group than server)
          :
          pams_attach_q()  // attach to a temp q
          pams_locate_q()  // bus-wide lookup to find the address of the
                           // server
          pams_put_msg()  //Send message to server...


Is the  shared name space file directory structure used to store
read/write data between Naming Agents?  Is this dynamically updated
by Naming Agents at run-time?  Can dynamic bus-wide queue alias
address resolution be done without the use of the shared directory 
structures?  (and without DNS)

Thanks,

Bob

T.R	Title	User	Personal Name	Date	Lines
2785.1		AZUR::GALVAN	Jean-Philippe GALVAN - Sophia-Antipolis - 828-5621	`Tue Feb 25 1997 03:23`	21
	>Is the shared name space file directory structure used to store >read/write data between Naming Agents? Naming Agents need to access the same file system, potentially using say NFS. >Is this dynamically updated by Naming Agents at run-time? Names are created in the namespace using the %GNT section or %QCT section. You can create a name like this in the GNT QUEUE1 0.0 G You can later attach any kind of queue (including a temporary queue) and bind it to the QUEUE1 name with pams_bind_q. When you detach the queue (or exit) the name is cleared. >Can dynamic bus-wide queue alias >address resolution be done without the use of the shared directory >structures? (and without DNS) No. But you can replicate %GNT entries in all init files and use group-wide name resolution. However, this will not allow you to have a queue binding at group level propagated to other groups.
2785.2	Too bad...	NWD002::GUNDERSON_RO		`Tue Feb 25 1997 19:27`	13
	This is unfortunate. It would be really nice if a shared file system was not required for this. I'm not sure why the Naming Agents could not coordinate bus-wide queue address/name resolution via the message bus rather than the file system. I guess we have to roll our own... again... TIBCO handles this with RMI API and Subject Based Addressing. Subject based addressing is built into Rv (Rendezvous) as a "primitive". Thanks for the information. Any other comments would be appreciated. Bob
2785.3	One namespace to avoid stale data	AZUR::GALVAN	Jean-Philippe GALVAN - Sophia-Antipolis - 828-5621	`Thu Feb 27 1997 02:37`	10
	A shared file is the only mechanism that guarantees accuracy of the queue address bound to a name. All other mechanisms open a window of error for a peer-to-peer communication using a broker - which the naming agent is. The file-based lightweight namespace is provided out-of-the box by DMQ. However, when VMS V4.0 is out, you can also use DECdns by having the naming agent(s) running on VMS hosts. Future releases of DMQ may support other independant namespace providers such as OSF DCE CDS or X500.
2785.4	Digital has it now	OZROCK::PERKINS	Some contractors, their sex-life destroyed and overwhelmed by project pressures, turn to snorting quack.	`Thu Feb 27 1997 19:44`	38
	The IMS/MSG+ product that layers on BMQ provides: Richer namespace and directory support using either Flatfile CDS DNS on all digital platforms (plus a number of non-digital platforms) Self-describing messages on all digital platforms (plus a number of non-digital platforms) Infinite sized messages on all digital platforms (plus a number of non-digital platforms) Server mgmt: start servers (adhoc or at boottime) stop servers ping dynamically control tracing and auditing server autorestart and/or notify of fail ODP Trader services SNMP and Polycenter Watchdog enabled Monitor: monitor all or selected servers server autodiscovery monitor dmq processes and logfiles monitor dce plus Plus more.... For more information please send mail to either Bob McKeating ([email protected]) Ken Jenkinson ([email protected]) or myself
2785.5	Does it have exactly what .0 requests for ?	AZUR::GALVAN	Jean-Philippe GALVAN - Sophia-Antipolis - 828-5621	`Fri Feb 28 1997 08:22`	15
	To the best of my knowledge, IMS/MSG+ does not provide the kind of feature requested in .0 that TIB claims having with its flat-file namespace, that is to say replicated decoupled files - or in-memory - with a protocol between name servers that coordinates the content with 100% accuracy. Last time I used, IMS/MSG+ needed also the flat file to reside on a shared file system. Otherwise the namespaces are disjoint, which DECmessageQ V4.0 supports too if it makes sense (for instance a namespace for the shop-floor groups and a namespace for the business management groups, or one for US, one for Europe and one for Australia ;-). On the other hand, global name services like DCE/CDS, DECdns or X500 (alphabetical order) provide this and IMS/MSG+ supports DECdns (also DMQ V4.0 when VMS is out) and DCE/CDS. On this last one, if it is important, please reply to Glen's note 2790.