Re: MIDRANGE-L Digest, Vol 6, Issue 1954

On 9/27/07, Elvis Budimlic <ebudimlic@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

<snip #1>

When my sql procedure bombs the system does not tell me the stmt
number where the error occured. When testing sql procedures from
STRSQL that return result sets I have to signoff and signon after
every test because otherwise the cursor stays open.

</snip #1>

I recommend using Run SQL Scripts to test stored procedures that return
result sets. You can see the data and I haven't run into issues with
cursors staying open.

<snip #2>

debugging an sql procedure is barely functional. ( have to know the C
structure my variables are declared in. cant use F10 to step to the next
stmt. )

</snip #2>

As for debugging, I went through the same pains, until I started using
visual iSeries System Debugger built into Run SQL Scripts. If you compile
your SQL PL stored procedures with option *DBGVIEW, you can actually step
through the SQL statements themselves, without looking at the ugly,
generated C code (unless you choose to do so, there is an option for it).
Once in Run SQL Scripts just hit Ctrl-D or click on Run->Debugger to invoke
it.

thanks for the tip, Elvis. not a possibility where I am working now.

<snip #3>

In RPG you cant read the result set.

</snip #3>

Yes you can, using CLI. It's not hard to use CLI if you've ever had to code
any ODBC code on other platforms.

With the V5R3 CL enhancements you can call a stored procedures in CL using
CLI as well. I've written a small sample of CL/CLI combo in of our
newsletter articles. That said, I do NOT encourage using CLI in CL... it's
ugly :)

I have made good money writing sql cli code for a client. I think it
is way too difficult to maintain the code. I would fire any
contractor ( like myself ) who stepped into a shop and wrote CLI from
RPG.

-Steve