[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

2757.0. "Implementation problem on VAX OpenVMS" by CARDHU::BOURAKOFF (MCS/STN-IM Switzerland 761-4820) Tue Feb 04 1997 10:36

        A customer for security reason want to implement such configuration
        using a temporary queue feature :
    
    1)    On Windows NT, DMQ 3.2 is running and send messages to a VAX
          (using OpenVMS 6.2 and DMQ 3.2) to a permanent queue (until now no
          problem) the messages arrived in the queue.
    2)    Then a pgm create a temporary queue on the VAX and read the
          message from the permanent queue and transfert it to a temporary 
    	  queue.
          but no messages seems to be transfered ... (No error message) but
    	  the temporary queue is create.
    3)    Windows NT then try to access that temporary queue (as long as
          the pgm is attached) and read those messages. 
    	  But the queue is empty ...
          
    Transfering messages from a permanent queue to a temporary queue is
    that possible ? and why no error message if something wrong occurs ?
    Of course I don't have the customer code :-(
    
    Pierre
T.RTitleUserPersonal
Name
DateLines
2757.1it sounds like there are some misconceptions...WHOS01::ELKINDSteve Elkind, Digital SI @WHOTue Feb 04 1997 11:0936
    Tranferring a message is no problem, assuming you are doing the
    following sequence on your VMS process:
    	1. attach to permanent queue
        2. attach to a temporary secondary queue
        3. get from the permanent queue
        4. put the same message body (and type, class if you need to) to
           the temp queue.  Note that you can't use a DQF or SAF delivery
           mode to a temp queue.
    1 and 2 can be reversed, if you want the temp queue as the primary.
    
    Now, for the problems:
    	1.  The WinNT client app cannot attach to a queue on another group,
            which it needs to do to read messages from it.
    	2.  Even if (1) weren't true, only one process can attach to a temp
            queue, and its contents disappear if the owner process detaches.
        3.  Even if (2) weren't true, you can not attach to a specific temp
            queue number, the group picks the number out of the bucket when
            you ask to attach to one.
    
    I assume what you really want to do is have the VMS server send to
    message back to a temp q on WinNT that the client process IS attached
    to already (you can't put to a temp queue which noone is attached to;
    it doesn't exist).  You can have the client specify that temp queue as
    the resp_q argument when it puts the original request.
    
    If the temp queue has to exist on the VMS system, your only solution is
    to have your WinNT client app built using the DmQ client library, and
    have it attach as a DmQ client to the VMS DmQ group.  You could
    probably set up CLS security so that the client can't attach to the
    permanent queue for reading (I'm not familiar with the VMS CLS setup,
    but I know you can do this on Unix DmQ).  Obviously, there is no DmQ
    group on WinNT which is involved with this.
    
    If none of this solves your problem, perhaps you can state the security
    problem they are trying to solve.
                                
2757.2thank youGENIE::BOURAKOFFMCS/STN-IM Switzerland 761 4820Wed Feb 05 1997 05:253
    Super thank's for the advise
    
    Pierre