Most examples on the web show that a DB2 stored procedure can be called from SQL Server through a linked server using:
exec sp_serveroption 'db2link', 'rpc', 'true'exec sp_serveroption 'db2link', 'rpc out', 'true'declare @in1, @in2, @outvar as char(3)set @in1 = 'ABC'set @in2 = 'GHI'exec db2link..schema.procname @in1, 'DEF', @in2exec db2link.location.schema.procname @in1, 'DEF', @in2exec db2link..schema.procname @in1, 'DEF', @in2, @outvar output
The rpc and rpc out options can also be set through the linked server proprerties. When location is specified, the stored procedure at that location would be executed through the database at the location specified by db2link.
However, although the driver returns output parameters from the linked server back to SQL Server, output variables are not set when the stored procedure is called this way. Consequently, this works only if the stored procedure has no output parameters, or if the values returned from the stored procedure (such as "@outvar" above) can be ignored, which is a bad thing if success or failure must be determined from those parameters.
In order to access the output parameters, the stored procedure must be called in this manner:
exec sp_serveroption 'db2link', 'rpc', 'true'exec sp_serveroption 'db2link', 'rpc out', 'true'declare @in1, @in2, @outvar as char(3)set @in1 = 'ABC'set @in2 = 'GHI'exec ('call schema.procname(?,?,?)', @in1, 'DEF', @in2, @outvar output) at db2link exec ('call location.schema.procname(?,?,?)', @in1, 'DEF', @in2, @outvar output) at db2link select @outvar
The string passed to the exec command is a native call statement. The question marks are placeholders for the parameters, which are bound to the variables specified in the command.
To access the result set:
select * from openquery(db2link, 'select * from SYSIBM.SYSDUMMY1')select * from openquery(oralink, 'select * from SYS.DUAL')