You can use BIND for a procedure, just create a local procedure instead of a routine.
Now, all of that said… are you sure that naming the routine to call is really the best approach?
Can you tell us a but about what you’re trying to accomplish.
The Routine Names are stored in a SQL Table along with Program Codes that get passed to a Global Data Processing application. The Routines are automatically executed in this application but they are currently called by name. I would like to use the SQL table field for Routine Names since I have a lot of external applications that trigger this process. In a nutshell I’m trying to streamline the code and create more visibility for the Routines shared by various applications.
Another thing you can do is create a case statement to suit:
RoutineName='CalculateSomething'
CASE RoutineName
OF 'CalculateSomething'
DO CalculateSomethingRoutine
OF 'SomethingElse'
DO SomethingElseRoutine
ELSE
Stop('Unknown routine named: ' & RoutineName)
END
Since you have to define and compile the routine in anyway, what are you trying to achieve by calling it from a variable?
Thanks Brahn, there are a LOT of routines involved and I want to avoid hard-coding names. The variable get sent to the Global Data Processing application from other applications via the “command” line therefore the most compact solution would involve using the variable as received.
Not sure if you found any solution, I would recommend to write your own template to do the job. It would be a procedure extension with a prompt for %input - match with the parameter name. Then you can call DO %input at the place you want. Hope that helps!