Meantime, I have used FETCH NEXT FROM CURSOR INTO:Data
Now the ‘Data’ field has the result of the query, but as we cannot say how lengthy the result can be, I have declared it as 9999A and thinking about moving it onto a display file screen field. Any better suggestions? Instead of embedded SQL I thought about RUNSQLSTM, but it requires additional source file for the SQL statements and it gives a chance for someone to change the SQL inside the source file. So I am not going for that. Please give your suggestions
 

To check the SQL statement, pass it to the Syntax Check SQL Statement (QSQCHKS) API. To display the output, there are three general ways.First, you can analyze the statement to determine the tables and libraries. Then determine the column list and retrieve the attributes of all columns that will be displayed. Define a SQL descriptor area (SQLDA) to hold column values according to their data types. You’ll need to work out out ways to dynamically display values on a screen without declaring the fields in a display file. There are various MI APIs that would be helpful. Most likely, this will take a couple months to get working.Second, you could pass the SQL into a REXX function or the Qshell db2 utility, and let them do most of the work. The db2 utility would probably be easiest. Almost as easy and probably a little cleaner would be passing the statement into a generic QM query, and running STRQMQRY to list the output. It should only take a day or so to get a generic QM query working. Numerous examples can be downloaded.But third and probably best might be just to let the system do it all for you. Why create something that you already have on the system? Just let the users type the SQL into QM query and run it. All that needs to be done is to create QM profiles for the users who need it. Authorize the users only to SELECT statements and you’re essentially done. There isn’t even any need for syntax checking ahead of time.Tom