
Charlie,
..exactly same situation I discovered. What puzzles me can be seen here:
This url points to the documentation for command RUNSQLSTM. Looking at the text for parameter COMMIT with “*RR” you’ll find this text:
“All tables referred to in SELECT, UPDATE, DELETE, and INSERT statements are locked exclusively until the end of the unit of work (transaction). ”
This is why I ask if somebody knows for sure if SELECT is Not supported with RUNSQLSTM.
DanF

Oops.. the editor tricked me with the url (I used the link-button…). Here it is as text:
http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=%2Fcl%2Frunsqlstm.htm
Pls concatenate the two lines into one (the editor still puzzles me..)
DanF

Is SELECT supported and what am I doing wrong?
Yes, but not as an executable statement.
The problem is that SELECT doesn’t actually do anything. In a sense, all it does is create an access path (incorrect, but it’s good enough for a concept). Once that’s done, you need to have something actually do something with it like FETCH rows, and then something has to do something with the rows.
If SELECT could make sense in RUNSQLSTM, what would you expect to happen to the rows?
I suspect that you’d like the rows to go to either a printer or a display. However, that kind of functionality is generally done by passing rows through a ReportWriter function.
In place of RUNSQLSTM, the STRQMQRY command may be used. Alternatively, a VIEW over a SELECT can be created with RUNSQLSTM, and basic RUNQRY can do print/display.
Tom



















