[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

2894.0. "Prob.access.remote RDB db due to DMQ3.2A-22" by EVTSG8::$VOGEL () Tue Jun 03 1997 14:48

    Hello,
    
    Following problem is arising and it seems due to DMQ 3.2A-22, (I do not
    know this sofware so ...).
    
    Situation;
            A Pascal program is doing an SQL set transaction where are
            involved 2 RDB databases on 2 different nodes. 
            The program blocks at the 
            SET TRANSACTION and does not go on, no error message.
            We know it is due to access to remote database.
            Also the only thing that has changed is migration of DMQ to
            V3.2A-22 on remote node (a cluster in fact). 
            The other detail that leaded
            us to DMQ was that the migration has only be done on one of the
            nodes of the cluster, using the node with old version of DMQ
            it works; Using the node with the version V3.2A-22 , it does
            not work;
            Any idea what we could do ? (System people plann to
            migrate second node to V3.2A-22 also no way to stop them so ...)
    
    Thank you for your help.
    Kind regards.                                           Georges.
            
T.RTitleUserPersonal
Name
DateLines
2894.1more information?WHOS01::ELKINDSteve Elkind, Digital SI @WHOTue Jun 03 1997 19:312
    What version is the "old" version?  Did they rebuild the application
    running on the node with the v3.2A-22 version?
2894.2PrecisionsEVTSG8::$VOGELWed Jun 04 1997 14:1723
    hello,
    
    The old version of DMQ on the node was v 3.2 (25).
    The extraction program is not running on the node where DMQ version has
    changed. In fact, generating a new executable for extraction has been
    done  in life environnement.
    
    May be I was not clear with my initial explanations. On one side we
    have a cluster (cluster A with 2 nodes (1 node with version v 3.2 (25) 
    of DMQ and on the other node v 3.2A-22) and on the other hand another cluster
    (cluster B). Extraction prog is running on one of the nodes from
    cluster B and is accessing a RDB database on cluster A. When we point
    to node 1 of cluster A with old version of DMQ it works, 
    when we point to node of cluster A 
    with new DMQ version extraction prog blocks (does not go on, no error
    message, no cpu, no IO ). 
    
    DO you have any idea what we could do ?
    
    Thank you for your help.
    
    Kind regards.				Georges.
    
2894.3Find out what you can do...PAMSRC::MICHELSENBEA/DEC MessageQ EngineeringWed Jun 04 1997 15:4814
re: .2

  ...by trying different MQ operations (i.e. looping messages, monitoring message counts...).  Also, you need to
look at the EVL log file to see if the messages are being lost.  I would then look at the problem process with SDA
to see if it's hung in an unusual process state (i.e. MWAIT), MQ programs wait for messages in LEF state.  Also,
in SDA, look and see if ASTs are turned off or the process is stuck in an AST.  From the DMQ$MGR_UTILITY you can
enable tracing on your process (assuming USER mode ASTs can get through) and watch the messaging traffic to the
process.

  Hopefully, the results of the info gathered will lead you to narrowing your problem.



Marty
2894.4for those with tunnel (80-col) visionWHOS01::ELKINDSteve Elkind, Digital SI @WHOWed Jun 04 1997 20:3824
         <<< PAMSRC::SYS$SYSDEVICE:[NOTES$LIBRARY]DECMESSAGEQ.NOTE;1 >>>
                          -< NAS Message Queuing Bus >-
================================================================================
Note 2894.3        Prob.access.remote RDB db due to DMQ3.2A-22            3 of 3
PAMSRC::MICHELSEN "BEA/DEC MessageQ Engineering"     14 lines   4-JUN-1997 11:48
                        -< Find out what you can do... >-
--------------------------------------------------------------------------------
re: .2

...by trying different MQ operations (i.e. looping messages, monitoring message
counts...).  Also, you need to look at the EVL log file to see if the messages
are being lost.  I would then look at the problem process with SDA to see if
it's hung in an unusual process state (i.e. MWAIT), MQ programs wait for
messages in LEF state.  Also, in SDA, look and see if ASTs are turned off or
the process is stuck in an AST.  From the DMQ$MGR_UTILITY you can enable
tracing on your process (assuming USER mode ASTs can get through) and watch the
messaging traffic to the process.

Hopefully, the results of the info gathered will lead you to narrowing your
problem.



Marty