| Author | 
		  Message
		 | 
		
		  | benfield | 
		  
		    
			  
				 Posted: Sat Feb 04, 2006 9:57 am    Post subject: Error 2087 returned from MQOPEN | 
				     | 
			   
			 
		   | 
		
		
		   Newbie
 
 Joined: 04 Feb 2006 Posts: 6
  
  | 
		  
		    
			  
				Hi folks,
 
 
C++ application to send and receive MQ messages via a SOAP server to a mainframe.  All is well until the message length reaches > 232 characters - then I get an error 2087 returned from the MQOPEN.
 
 
Any ideas.   
 
 
Thanks 
 
 
Andy | 
			   
			 
		   | 
		
		
		  | Back to top | 
		  
		  	
		   | 
		
		
		    | 
		
		
		  | vennela | 
		  
		    
			  
				 Posted: Sat Feb 04, 2006 10:21 am    Post subject:  | 
				     | 
			   
			 
		   | 
		
		
		    Jedi Knight
 
 Joined: 11 Aug 2002 Posts: 4055 Location: Hyderabad, India 
  | 
		  
		    
			  
				This error has got nothing to do with lenght of the message. 
 
mqrc on that error code gives
 
 
   
	| Code: | 
   
  
	|  2087  0x00000827  MQRC_UNKNOWN_REMOTE_Q_MGR | 
   
 
 | 
			   
			 
		   | 
		
		
		  | Back to top | 
		  
		  	
		   | 
		
		
		    | 
		
		
		  | benfield | 
		  
		    
			  
				 Posted: Sat Feb 04, 2006 10:47 am    Post subject:  | 
				     | 
			   
			 
		   | 
		
		
		   Newbie
 
 Joined: 04 Feb 2006 Posts: 6
  
  | 
		  
		    
			  
				I realise that, vennela, but I've debugged all the values sent to the MQOPEN  and even set them back to their original value (those for a  successful open), just before, the MQOPEN statement. It still fails with a 2087 error when the message gets over a certain length, so something else must be getting corrupted. 
 
 
Are there any installation settings to check?  I'm a bit new at this!
 
 
I also tried to use the VB6 equivalent test program from the Websphere installation tools library, but it couldn't find MQM.DLL so this wouldn't work.
 
 
Thanks for your help
 
 
Andy | 
			   
			 
		   | 
		
		
		  | Back to top | 
		  
		  	
		   | 
		
		
		    | 
		
		
		  | wschutz | 
		  
		    
			  
				 Posted: Sat Feb 04, 2006 10:58 am    Post subject:  | 
				     | 
			   
			 
		   | 
		
		
		    Jedi Knight
 
 Joined: 02 Jun 2005 Posts: 3316 Location: IBM (retired) 
  | 
		  
		    
			  
				
   
	| Quote: | 
   
  
	| Are there any installation settings to check? | 
   
 
No.  It looks like the MQOD structure is getting overlaid (specifically the ObjectQMgrName file).  Can you check that before the MQOPEN is issued.
 
 
Also, I'm a bit confused .... are you opening the queue before you write each message? _________________ -wayne | 
			   
			 
		   | 
		
		
		  | Back to top | 
		  
		  	
		   | 
		
		
		    | 
		
		
		  | benfield | 
		  
		    
			  
				 Posted: Sat Feb 04, 2006 11:24 am    Post subject:  | 
				     | 
			   
			 
		   | 
		
		
		   Newbie
 
 Joined: 04 Feb 2006 Posts: 6
  
  | 
		  
		    
			  
				Hi wschutz,
 
 
Yes, this is an exe file that gets its value sent to it from from a dll via standard windows messaging system a block length of 50000.  (Don't ask me why, I didn't design it !)  As such the queue is opened and closed for each message.
 
 
 
I've printed out every element of the MQOD structure and even reset them all to their original values (including the ObjectQMgrName and the RemoteQMgrName to '\0)' just before issuing an MQOPEN. It still fails when the message gets over a certain length. Does MQOPEN rely on something other than the specific parameters passed in (e.g. an external ini file or registry setting)?   
 
 
Thanks for your help.
 
 
Andy | 
			   
			 
		   | 
		
		
		  | Back to top | 
		  
		  	
		   | 
		
		
		    | 
		
		
		  | wschutz | 
		  
		    
			  
				 Posted: Sat Feb 04, 2006 1:50 pm    Post subject:  | 
				     | 
			   
			 
		   | 
		
		
		    Jedi Knight
 
 Joined: 02 Jun 2005 Posts: 3316 Location: IBM (retired) 
  | 
		  
		    
			  
				
   
	| Quote: | 
   
  
	Does MQOPEN rely on something other than the specific parameters passed in (e.g. an external ini file or registry setting)?
 
 | 
   
 
No, just what you pass it.
 
 
You mention this is a C++ application...are you using the standard "c' api's (ie MQCONN, MQOPEN...) or the c++ classes?
 
 
Are you using client or server bindings? _________________ -wayne | 
			   
			 
		   | 
		
		
		  | Back to top | 
		  
		  	
		   | 
		
		
		    | 
		
		
		  | benfield | 
		  
		    
			  
				 Posted: Sat Feb 04, 2006 2:48 pm    Post subject:  | 
				     | 
			   
			 
		   | 
		
		
		   Newbie
 
 Joined: 04 Feb 2006 Posts: 6
  
  | 
		  
		    
			  
				(1) standard extern ''C' MQCONN and MQOPEN
 
 
(2) program is dynamically linked to mq client lib - is that what you mean? | 
			   
			 
		   | 
		
		
		  | Back to top | 
		  
		  	
		   | 
		
		
		    | 
		
		
		  | wschutz | 
		  
		    
			  
				 Posted: Sun Feb 05, 2006 5:15 am    Post subject:  | 
				     | 
			   
			 
		   | 
		
		
		    Jedi Knight
 
 Joined: 02 Jun 2005 Posts: 3316 Location: IBM (retired) 
  | 
		  
		    
			  
				Perhaps you should take a trace of the MQ client, you'll be able to see the MQOD that its pasing along the channel to the server.
 
 
To turn on tracing:
 
   
	| Code: | 
   
  
	
 
strmqtrc (add -e for unix)
 
run your app
 
endmqtrc (add -e for unix)
 
cd \mqminstall\trace
 
dspmqtrc <tracefile>
 
 | 
   
 
 
 
You should see the MQOPEN call with the MQOD:
 
   
	| Quote: | 
   
  
	
 
08:06:57.340515     9596.1          MQOPEN <<
 
 08:06:57.340528     9596.1          Hconn         : Input  Parm
 
 08:06:57.340541     9596.1          Objdesc:
 
 08:06:57.340555     9596.1            0x0000:  4f442020 01000000 01000000 54455354  |OD  ........TEST|
 
 08:06:57.340555     9596.1            0x0010:  00000000 00000000 00000000 00000000  |................|
 
 08:06:57.340555     9596.1            0x0020:  00000000 00000000 00000000 00000000  |................|
 
 08:06:57.340555     9596.1            0x0030:  00000000 00000000 00000000 00000000  |................|
 
 08:06:57.340555     9596.1            0x0040:  00000000 00000000 00000000 00000000  |................|
 
 08:06:57.340555     9596.1            0x0050:  00000000 00000000 00000000 00000000  |................|
 
 08:06:57.340555     9596.1            0x0060:  00000000 00000000 00000000 414d512e  |............AMQ.|
 
 08:06:57.340555     9596.1            0x0070:  2a000000 00000000 00000000 00000000  |*...............|
 
 08:06:57.340555     9596.1            0x0080:  00000000 00000000 00000000 00000000  |................|
 
 08:06:57.340555     9596.1            0x0090:  === Skipping 12 Duplicate Lines ===  |................|
 
 08:06:57.340568     9596.1          Options       : Input  Parm
 
 08:06:57.340581     9596.1          Hobj:
 
 08:06:57.340593     9596.1            0x0000:  78dc3508                             |x.5.            |
 
 08:06:57.340606     9596.1          Compcode:
 
 08:06:57.340619     9596.1            0x0000:  00000000                             |....            |
 
 08:06:57.340632     9596.1          Reason:
 
 08:06:57.340644     9596.1            0x0000:  00000000                             |....            |
 
 08:06:57.340656     9596.1     -}  MQOPEN rc=OK
 
 08:06:57.340698     9596.1          ObjHandle=137747576 ObjType=1 ObjName=TEST
 
 08:06:57.340712     9596.1     }  MQOPEN rc=OK
 
 | 
   
 
 
 
Are you specifying a ObejctQMgrName or leaving that blank?  With any luck, you'll see something in the MQOD that will point to the problem.  If everything looks OK, then something else is going on   _________________ -wayne | 
			   
			 
		   | 
		
		
		  | Back to top | 
		  
		  	
		   | 
		
		
		    | 
		
		
		  | benfield | 
		  
		    
			  
				 Posted: Sun Feb 05, 2006 5:29 am    Post subject:  | 
				     | 
			   
			 
		   | 
		
		
		   Newbie
 
 Joined: 04 Feb 2006 Posts: 6
  
  | 
		  
		    
			  
				| Thanks Wayne - I'll try that and report back. | 
			   
			 
		   | 
		
		
		  | Back to top | 
		  
		  	
		   | 
		
		
		    | 
		
		
		  | benfield | 
		  
		    
			  
				 Posted: Fri Feb 10, 2006 1:54 pm    Post subject:  | 
				     | 
			   
			 
		   | 
		
		
		   Newbie
 
 Joined: 04 Feb 2006 Posts: 6
  
  | 
		  
		    
			  
				Guys,
 
 
I wasn't able to post this from the client site during the week, but I'd like to report success thanks to your help.
 
 
The problem was eventually traced to a tracing statment that had been put into the calling program being set as static[256] char.  When a message > 232 =(256-24 (for the envelope) ) was traced, it was overwriting all sorts of buffers.
 
 
All sorted now.  May I say how responsive you guys have been. Wayne, the diagnostic statements you recommended were really helpful.
 
 
Regards
 
 
Andy | 
			   
			 
		   | 
		
		
		  | Back to top | 
		  
		  	
		   | 
		
		
		    | 
		
		
		  | 
		    
		   |