Re: Calling SQL from QSH was: CPYTOSTMF

Hi Keith,

Interesting post Dennis - this is the first time I've seen a reference
to calling SQL from QSH. Are there any restrictions in calling SQL this
way?

Restrictions... it doesn't support *SYS naming convention, it only supports *SQL. That means it can't use *LIBL, which is frustrating. Also, when you invoke a stored procedure or function that's written in an HLL like RPG, you have no control over that routine's *LIBL.

Another problem: It prints all error messages to STDOUT instead of STDERR. And when something fails, it still sets the exit status to 0 (all other Unix utilities set it to a non-zero value to indicate failure). That makes it very difficult to do error checking with db2.

Another problem: It always prints extra info like column headings and other informational messages. That's fine if you're using it as an interactive tool, but when you're trying to read the result into a program, it requires extra code to strip out the headings, etc.

In fact, these restrictions get in my way so frequently that I ended up writing my own work-alike command that solves the problems. (See the links below)

Are there any other references?

Many. Here are the articles that I, personally, have written about it. I'm sure there are many many other references...

http://systeminetwork.com/article/qshell-does-sql
http://systeminetwork.com/article/read-sql-result-sets-cl-qshell
http://systeminetwork.com/article/create-physical-file-cl
http://systeminetwork.com/article/write-your-own-custom-csv-export-utility-without-apis
http://systeminetwork.com/article/improved-db2-command-qshell