[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

2786.0. "Loosing ENABLE_NOTIFY responses - not sure where though..." by OZROCK::THOMAN (The House Of Script) Mon Feb 24 1997 22:55

	I have a Digital UNIX process that connects to
	a temporary primary q using  Digital's IMS 
	product (asset ;-). It then issues a pams_attach_q()
	to a secondary temp q.

	After these 2 connects are successfull, it 
	issues an MSG_TYPE_ENABLE_NOTIFY (wanting both
	link & q activity notifications) to the 
	PAMS_CONNECT_SERVER queue.

	As A test, I start a 2nd copy of the program
	(ie: it will issue the same 2 connects).
	Currently, I am only notified of 1 connect when 
	the second process is started - but I am notified of 
	TWO disconnects when the second is terminated.

	The way my app works is on every notification of
	a connection, I try perform on "IMS Ping" to the
	q specified in the MSG_TYPE_PROCESS_DCL response.

	(Quick Side Track To "Explain" IMS Ping: I'm not sure 
	of your IMS knowledge, but basically it is an SL_ORGANIC
	class message that the IMS layer of a process picks 
	up & responds too without passing the msg up to the 
	IMS application code). One of the IMS engineers would 
	be able to give ya a better explaination - infact Mr. B.
	McKeating is wandering around this office in Queensland,
	Australia today)

	Since that second (test) copy of my app connects to
	a primary q, one E'_NOTIFY response is rcvd, & the IMS
	Ping is attempted. When the test connects to the 2ndry
	temp q, the IMS Ping is still happening. When the IMS
	Ping completes for the 1st E'_NOTIFY response, there
	should be a 2nd  E'_NOTIFY response waiting but there
	is NOT. 

	All IMS Pings & the reading of the Ping response are
	done on the app's Primary Q. 

	I register the ENABLE_NOTIFY with a pams_put_msg, after
	earlier doing the pams_attach to the 2ndry Q.
	Does this mean **ALL** E'_NOTIFY responses will be sent
	to that 2ndry Q, cause that's the key assumption I'm 
	making.
	
	All pams_..() & sl_...() (IMS) function return codes 
	are tested, and I am not seeing any errors.

	If I remove the call to the function which performs
	the IMS Ping, then, yes, I DO see 2 connection 
	notifications. 
	

	Also, as another test, I run the IMS "masterc" - a
	simple  dmq process that: connects, issues 1 req, rcvs 
	1 resp, then disconnects. Unless the IMS Ping read
	timeout is short (around 1 sec or less) I usually don't 
	see the disconnect notification for masterc.

	Sorry for the confusion you are undoubtly having at the 
	moment trying to understand this. feel free to ask for
	clarrifications.	
	

The details of my system where I build & run are:

# setld -i | grep DECmessageQ
DMACL32A        installed       DECmessageQ Client Library
DMACLS32A       installed       DECmessageQ Client Library Server
DMADEV32A       installed       DECmessageQ Development Environment
DMAECO132A      installed       DECmessageQ V3.2A (ECO 1)
DMAEXA32A       installed       DECmessageQ Example Programs
DMAMAN32A       installed  	DECmessageQ Manual Reference Pages
DMARLS32A       installed       DECmessageQ Release Notes
DMARTO32A       installed       DECmessageQ Run Time Environment

# uname -a
OSF1 mynode.ozy.dec.com V3.2 148 alpha	
# su - dmq	
% foreach file ( dmqgcp dmqqe dmqbcp dmqld )
? echo $file
? what `which $file` | grep DECmessageQ
? end
dmqgcp
        DECmessageQ for UNIX, V3.2A, Sun Nov 24 00:01:39 EST 1996
dmqqe
        DECmessageQ for UNIX, V3.2A, Sun Nov 24 00:01:39 EST 1996
dmqbcp
        DECmessageQ for UNIX, V3.2A, Sun Nov 24 00:01:39 EST 1996
dmqld
        DECmessageQ for UNIX, V3.2A (ECO 1), Mon Feb 2 00:00:00 EST 1997
%

T.R	Title	User	Personal Name	Date	Lines
2786.1	script capture and tracing ?	XHOST::SJZ	Rocking the Messaging Desktop !	`Mon Feb 24 1997 23:41`	27
	not knowing the first thing about IMS, i have some questions. you say you 1) attach to a temporary queue 2) attach to a secondary temporary q 3) send an ENABLE_NOTIFY to the PAMS_CONNECT_SERVER 4) you post a get ? 5) startup the same program without exiting the first my question is which of these steps are done by you and which of these steps are done by IMS ? Basically i want to know if it works without IMS. If it does then I defer to the IMS people to track down the prob- lem. If it doesn't then maybe it is our problem. one thing to try is to turn on scripting (to see what messages you are sending and receiving). once you have the output, you can check to see what you are actually receiving from the connect server and what IMS is actually passing back to you. You are likely to get a lot of noise from the internal IMS messaging, but there really isn't a better way to find out what is happening. tracing may also be useful, but is harder to read and you can't see the message content. _sjz.
2786.2	RE .1 - what's Me	OZROCK::THOMAN	The House Of Script	`Tue Feb 25 1997 01:23`	171
	> not knowing the first thing about IMS, i have some > questions. you say you > 1) attach to a temporary queue > 2) attach to a secondary temporary q > 3) send an ENABLE_NOTIFY to the PAMS_CONNECT_SERVER > 4) you post a get ? > 5) startup the same program without exiting the first > > my question is which of these steps are done by you > and which of these steps are done by IMS ? I do all 5 steps. By "post a get" I assume you mean call pams_get_msgw() ? I call pams_get_msgw() on that 2ndry temp q. I perform reads with a configurable timeout - usually 20 secs. Is my assumption from .0 correct??: ie: >> I register the ENABLE_NOTIFY with a pams_put_msg, after >> earlier doing the pams_attach to the 2ndry Q. >> Does this mean ALL E'_NOTIFY responses will be sent >> to that 2ndry Q, cause that's the key assumption I'm >> making. All IMS stuff should only be happening on the primary q (also temporary). It should not be touching my 2ndry q - atleast that is what I understand, and will get confirmation from an IMS engineer. > Basically > i want to know if it works without IMS. If it does > then I defer to the IMS people to track down the prob- > lem. If it doesn't then maybe it is our problem. > Assuming IMS doesn't touch the 2ndry Q, and my assumption above is correct, then I believe it is in the DMQ ball-park. > one thing to try is to turn on scripting (to see what > messages you are sending and receiving). once you > have the output, you can check to see what you are > actually receiving from the connect server and what > IMS is actually passing back to you. You are likely I tried running with PAMS_TRACE setenv'd to 1. Can u pls give me an into to understanding its output ? Here's the trace from my process as I start a 2nd copy of it. 16:17:39:167: dmq_poller.cxx:2881 ==> DmqReadMsg(): timeout (1/10ths sec): 600 <in a blocking read for 60 seconds here> 16:18:02:230: dmq_poller.cxx:2987 - Process CONNECT to 2966.731 16:18:02:231: dmq_poller.cxx:1470 ==> ImsPing(): timeout (1/10ths sec): 1 16:18:02:345: dmq_poller.cxx:1625 <== ImsPing() 16:18:02:345: dmq_poller.cxx:3224 <== DmqReadMsg() - status: PAMS__SUCCESS 16:18:02:345: dmq_poller.cxx:2881 ==> DmqReadMsg(): timeout (1/10ths sec): 600 16:18:09:757: dmq_poller.cxx:3024 - Process DISCONNECT from 2966.708 16:18:09:758: dmq_poller.cxx:3224 <== DmqReadMsg() - status: PAMS__SUCCESS 16:18:09:758: dmq_poller.cxx:2881 ==> DmqReadMsg(): timeout (1/10ths sec): 600 16:18:09:763: dmq_poller.cxx:3024 - Process DISCONNECT from 2966.731 16:18:09:764: dmq_poller.cxx:3224 <== DmqReadMsg() - status: PAMS__SUCCESS 16:18:09:764: dmq_poller.cxx:2881 ==> DmqReadMsg(): timeout (1/10ths sec): 600 <back to the blocking read for 60 seconds> As u can see, 2 disconnects, but only 1 connect, even when the IMS read only blocked for 1/10th of a second. Here is the PAMS_TRACE for that run. I've tried looking through the p_.h files to find meanings for some of the numbers below, but no luck. PAMS 10636:PAMS-*** received message ** PAMS 10636:PAMS-IPI Type :, 19 (13) PAMS 10636:PAMS-Source :, 194379876 (B960064) PAMS 10636:PAMS-Target :, 194380502 (B9602D6) PAMS 10636:PAMS-Type / Class:, -65011683 (FC20001D) PAMS 10636:PAMS-Priority : PAMS 10636:PAMS-Length :, 4 (4) PAMS 10636:PAMS-IPI Del Opt : PAMS 10636:PAMS-IPI UMA :, 1 (1) PAMS 10636:PAMS-Msg Seq High:, 892571 (D9E9B) PAMS 10636:PAMS-Msg Seq Low :, 194379875 (B960063) PAMS 10636:PAMS-************************** PAMS 10636:PAMS-PAMS_get_cleanup PAMS 10636:PAMS-** sending message ** PAMS 10636:PAMS-Source :, 194380502 (B9602D6) PAMS 10636:PAMS-Destination :, 194380507 (B9602DB) PAMS 10636:PAMS-Redirected to :, 194380507 (B9602DB) PAMS 10636:PAMS-Type / Class :, 3276850 (320032) PAMS 10636:PAMS-Delivery :, 29 (1D) PAMS 10636:PAMS-UMA :, 5 (5) PAMS 10636:PAMS-Resp Q : PAMS 10636:PAMS-************************** PAMS 10636:PAMS-** sent message ** PAMS 10636:PAMS-Msg Seq High:, 1669 (685) PAMS 10636:PAMS-Msg Seq Low :, 194380785 (B9603F1) PAMS 10636:PAMS-************************** PAMS 10636:PAMS-Received unblocking msg PAMS 10636:PAMS-PAMS_put_cleanup PAMS 10636:PAMS-PAMS_deq PAMS 10636:PAMS-** received message ** PAMS 10636:PAMS-IPI Type :, 19 (13) PAMS 10636:PAMS-Source :, 194379876 (B960064) PAMS 10636:PAMS-Target :, 194380502 (B9602D6) PAMS 10636:PAMS-Type / Class:, -65011683 (FC20001D) PAMS 10636:PAMS-Priority : PAMS 10636:PAMS-Length :, 4 (4) PAMS 10636:PAMS-IPI Del Opt : PAMS 10636:PAMS-IPI UMA :, 1 (1) PAMS 10636:PAMS-Msg Seq High:, 893339 (DA19B) PAMS 10636:PAMS-Msg Seq Low :, 194379875 (B960063) PAMS 10636:PAMS-************************** PAMS 10636:PAMS-PAMS_get_cleanup PAMS 10636:PAMS-PAMS_deq PAMS 10636:IPI-Dequeue Message failed, -42 (FFFFFFD6) PAMS 10636:PAMS-PAMS_get_cleanup PAMS 10636:PAMS-PAMS_deq PAMS 10636:PAMS-** received message ** PAMS 10636:PAMS-IPI Type :, 19 (13) PAMS 10636:PAMS-Source :, 194379876 (B960064) PAMS 10636:PAMS-Target :, 194380502 (B9602D6) PAMS 10636:PAMS-Type / Class:, -65077219 (FC1F001D) PAMS 10636:PAMS-Priority : PAMS 10636:PAMS-Length :, 4 (4) PAMS 10636:PAMS-IPI Del Opt : PAMS 10636:PAMS-IPI UMA :, 1 (1) PAMS 10636:PAMS-Msg Seq High:, 894875 (DA79B) PAMS 10636:PAMS-Msg Seq Low :, 194379875 (B960063) PAMS 10636:PAMS-************************** PAMS 10636:PAMS-PAMS_get_cleanup PAMS 10636:PAMS-PAMS_deq PAMS 10636:PAMS-** received message ** PAMS 10636:PAMS-IPI Type :, 19 (13) PAMS 10636:PAMS-Source :, 194379876 (B960064) PAMS 10636:PAMS-Target :, 194380502 (B9602D6) PAMS 10636:PAMS-Type / Class:, -65077219 (FC1F001D) PAMS 10636:PAMS-Priority : PAMS 10636:PAMS-Length :, 4 (4) PAMS 10636:PAMS-IPI Del Opt : PAMS 10636:PAMS-IPI UMA :, 1 (1) PAMS 10636:PAMS-Msg Seq High:, 895899 (DAB9B) PAMS 10636:PAMS-Msg Seq Low :, 194379875 (B960063) PAMS 10636:PAMS-**************************** PAMS 10636:PAMS-PAMS_get_cleanup PAMS 10636:PAMS-PAMS_deq Thanks !! Craig.
2786.3	Lots of gap between q numbers in .2 example not the norm.	OZROCK::THOMAN	The House Of Script	`Tue Feb 25 1997 01:29`	25
	Re.2 I just noticed: >16:18:09:757: dmq_poller.cxx:3024 - Process DISCONNECT from 2966.708 >16:18:09:758: dmq_poller.cxx:3224 <== DmqReadMsg() - status: PAMS__SUCCESS >16:18:09:758: dmq_poller.cxx:2881 ==> DmqReadMsg(): timeout (1/10ths sec): 600 >16:18:09:763: dmq_poller.cxx:3024 - Process DISCONNECT from 2966.731 Normally the the 2 q's are connecutive numbers. This is the 1st time I've ever seen it otherwise. Must have been a lot of activity on the machine at that time. Also > u pls give me an into to understanding its output ? ^^^^ should be intro C
2786.4		XHOST::SJZ	Rocking the Messaging Desktop !	`Tue Feb 25 1997 10:17`	20
	by you, i mean are you calling pams_xxx_yyy or are you calling some IMS function which calls pams_xxx_yyy ? according to the trace 1) received a MSG_TYPE_PROCESS_DCL from queue 100. 2) sent a message of type 32, class 32 to queue 731. 3) received a MSG_TYPE_PROCESS_DCL from queue 100. 4) timed out an a get 5) received a MSG_TYPE_DISABLE_NOTIFY from queue 100 6) received a MSG_TYPE_DISABLE_NOTIFY from queue 100 I can't tell what you are being notified of since this is a trace and not a script log of messages received. But given that description above (receipt of two PROCESS_DCL's and two DISABLE_NOTIFY's) how does this differ from what you are expecting ? _sjz.
2786.5	DISABLE_NOTIFY ??	OZROCK::THOMAN	The House Of Script	`Tue Feb 25 1997 19:18`	86
	I never expect to get a DISABLE_NOTIFY ! What I am expection is: 2 x MSG_TYPE_PROCESS_DCL then 2 x MSG_TYPE_PROCESS_EXIT If your seeing MSG_TYPE_DISABLE_NOTIFY in that trace then does that mean DMQ believes I sent it a DISABLE_NOTIFY request ? For the entire life of my process, it always wants to rcv notifications of Links Up or Down, or Q's attaching & detaching. If that's what the trace shows, then that's probably part of the problem(s) I'm seeing. PLEASE TELL ME IF MY ASSUMPTION CORRECT >>> I register the ENABLE_NOTIFY with a pams_put_msg, after >>> earlier doing the pams_attach to the 2ndry Q. >>> Does this mean ALL E'_NOTIFY responses will be sent >>> to that 2ndry Q, cause that's the key assumption I'm >>> making. The Test, Step by Step. ======================= 1. Start 1st instance of the Application (call this one "Poller") a. Call sl_connect.. (IMS) routine. It attaches to a primary Q. b. Call pams_attach_q() It attaches to a 2ndry Q. c. Call pams_put_msg() to send a MSG_TYPE_ENABLE_NOTIFY d. Call pams_get_msgw() in an infinite loop, with a timeout of 20->60 secs. 2. Start another instance of the Application (call this one Test) Hence it goes through steps a -> d itself. 3. "Poller" rcvs a MSG_TYPE_PROCESS_DCL as "Test" does its' step (a). 4. "Poller" issues the IMS Ping to the group.queue it got out of the MSG_TYPE_PROCESS_DCL message it just rcvd. To do this an IMS message is sent on the primary Q setup in 1.(a). A read for a "short" time is done on that primary Q is performed, waiting for the ping response. As it turns out, no Ping response comes back. This probably explains step "4)" in -.1. >> 4) timed out an a get While this step 4 has been going on, "Test" would've performed its' step (b). Hence another MSG_TYPE_PROCESS_DCL should be sent to "Poller". This is the message I am not seeing. I don't tell the IMS API (now called MSG+) I have a 2ndry Q. I don't know if it can find out. Can you guarantee the PAMS_CONNECT_SERVER is sending the notifications to the 2ndry Q ?? I know if they're going to the Primary Q, IMS will be discarding them which is why I'm not seeing them. That is why it is SO IMPORTANT someone please tell me the answer to my assumption. Thanks, Craig.
2786.6		XHOST::SJZ	Kick Butt In Your Face Messaging !	`Tue Feb 25 1997 21:01`	26
	whoops. you are right. i mistranslated the numbers. you ARE getting two DCL and two EXITS. your registra- tion was made from queue 726 and the MSG_TYPE_PROCESS_ messages are going to queue 726. when you are registering for the ENABLE_NOTIFY are you supplying a response queue ? if not then the connect server thinks the message came from your primary queue and will send responses and notifications to that address, and if that is the queue attached by IMS, then you probably get nothing. without the full trace (from the beginning so i can see the attachments (you would need the IPI trace as well)) i can't really tell if you supplied a response queue. one more note. you may notice that the PROCESS_DCL and PROCESS_EXIT messages have not appeared in the documentation for over 4 years now. that is because they were obsoleted when we switched from PAMS to DMQ. well in V4.0 they are going away completely. look at the V4.0 version of p_typecl.h. the definitions are gone. you may want to consider the AVAIL/UNAVAIL ser- vice instead (which requires SBS), or ENABLE_Q_NOTIFY. _sjz.
2786.7	Looks like it is our fault. - as I original suspected.	OZROCK::THOMAN	The House Of Script	`Tue Feb 25 1997 22:48`	68
	> when you are registering for the ENABLE_NOTIFY are you > supplying a response queue ? if not then the connect > server thinks the message came from your primary queue > and will send responses and notifications to that > address, and if that is the queue attached by IMS, > then you probably get nothing. Yes & No. When I tried using a response Q, I got nothing at all, so I went back to not specifing one. The reason I wasn't rcv'ing any thing on the response q was my selection filter on the pams_get_msgw() was broken !! That puts this note in the User-Error basket, (hence why I deleted the original version of this note) a developers favourite type! My filter is now: int32 selectnFilter = (PSEL_AQ << 16) \| qAddress.au.queue; dmqStatus = pams_get_msgw(msgArea, ..., &selectnFilter, ..., ...); Can u see any problem with that ? > one more note. you may notice that the PROCESS_DCL > and PROCESS_EXIT messages have not appeared in the > documentation for over 4 years now. I've been having to work with Jan 1994 Prog' Guide. I asked the other day in another note for something newer. The answer was wait until .ps versions of ya html doc have been created. > .....in V4.0 they are going away Thanks ! I've logged it as a bug against our apps that use it. > or ENABLE_Q_NOTIFY. As long as we can still get q AND link notifications, and the transition from the old stuff to these new ones isn't too painful, we'll be right I think. Sorry for "run"- around. Thx Craig.
2786.8		XHOST::SJZ	Kick Butt In Your Face Messaging !	`Wed Feb 26 1997 00:22`	8
	that selection filter looks correct. there were updated programmer's guides released in 5/94 and 2/95 as well. as for the transition to ENABLE_Q_NOTIFY it is not really all that painful, but it depends on your level of encapsulation. _sjz.
2786.9	thanks! - C.	OZROCK::THOMAN	The House Of Script	`Wed Feb 26 1997 19:28`	0