| Author | 
		  Message
		 | 
		
		  | shassey | 
		  
		    
			  
				 Posted: Sat Jan 12, 2002 2:55 pm    Post subject:  | 
				     | 
			   
			 
		   | 
		
		
		   Apprentice
 
 Joined: 25 Dec 2001 Posts: 25 Location: shassey 
  | 
		  
		    
			  
				Is there any way to capture db2 return codes in mqsi?   I know that if a 'not found' occurs, your xml will be null but what about other return codes?    Some appear in the event log but not all.    I would like to capture them in the flow so that I can report the appropriate information to the support staff.
 
 
Thanks in advance for any help! | 
			   
			 
		   | 
		
		
		  | Back to top | 
		  
		  	
		   | 
		
		
		    | 
		
		
		  | zpat | 
		  
		    
			  
				 Posted: Mon Jan 14, 2002 4:38 am    Post subject:  | 
				     | 
			   
			 
		   | 
		
		
		    Jedi Council
 
 Joined: 19 May 2001 Posts: 5867 Location: UK 
  | 
		  
		    
			  
				| WMQI 2.1 has added support for SQL return codes. | 
			   
			 
		   | 
		
		
		  | Back to top | 
		  
		  	
		   | 
		
		
		    | 
		
		
		  | mpuetz | 
		  
		    
			  
				 Posted: Tue Jan 15, 2002 5:11 pm    Post subject:  | 
				     | 
			   
			 
		   | 
		
		
		   Centurion
 
 Joined: 05 Jul 2001 Posts: 149 Location: IBM/Central WebSphere Services 
  | 
		  
		    
			  
				Hi,
 
 
as always life before 2.1 is hard, very hard.
 
 
In 2.0.x the only way to find out about SQL return codes is by analysing the exception list when a SQL exception is thrown. The codes
 
can be found usually at the second ot third nesting level in the the inserts section of the exception list tree, depending on where you
 
capture the exception. You can catch it in a  localized fashion in the failure exit of a node or in a centralized way in try/catch node (or the input node for that respect) in the catch tree. You must evaluate it in a copmute node and based on what you get add your own error handler.
 
The typical strategy with fine grained database error handling usually works like this:
 
Do only a single database action per node
 
so you can be sure about the cause of an exception (you can find out the SQL statement from the exception list, too, if you want to).
 
 
 
 
 _________________ Mathias Puetz
 
 
IBM/Central WebSphere Services
 
WebSphere Business Integration Specialist | 
			   
			 
		   | 
		
		
		  | Back to top | 
		  
		  	
		   | 
		
		
		    | 
		
		
		  | NickB | 
		  
		    
			  
				 Posted: Wed Jan 16, 2002 3:22 am    Post subject:  | 
				     | 
			   
			 
		   | 
		
		
		   Centurion
 
 Joined: 20 May 2001 Posts: 107 Location: Zurich Financial Services 
  | 
		  
		    
			  
				| Don't forget there is also a support pac IA0J which will allow you to easily interrogate the returned SQL code without manually parsing the exception list. | 
			   
			 
		   | 
		
		
		  | Back to top | 
		  
		  	
		   | 
		
		
		    | 
		
		
		  | mpuetz | 
		  
		    
			  
				 Posted: Thu Jan 17, 2002 8:41 am    Post subject:  | 
				     | 
			   
			 
		   | 
		
		
		   Centurion
 
 Joined: 05 Jul 2001 Posts: 149 Location: IBM/Central WebSphere Services 
  | 
		  
		    
			  
				True, but it's support pack categrory 2,
 
so: use at your own risk ! And since
 
MQSI 2.1 has a more elegant way of doing
 
this you will probably never get support
 
for this. None of my customers ever
 
accepted usage of category 2 in critical
 
parts of my flows. Mike Brady's IA0J comes
 
with source code though, which in turn
 
makes it acceptable for me.
 
Parsing the exception list manually
 
is fully support though.
 
 _________________ Mathias Puetz
 
 
IBM/Central WebSphere Services
 
WebSphere Business Integration Specialist | 
			   
			 
		   | 
		
		
		  | Back to top | 
		  
		  	
		   | 
		
		
		    | 
		
		
		  | 
		    
		   |