Re: Run SQL statement output

Lance Gillespie wrote:

When I run a CL that has a RunSQLStm in it, it produces a spool file
listing the source and run parameters and warnings even though
I specify OUTPUT(*NONE) for the Listing output parameter on the RunSQLStm command.

We are on v5r4.

How do I suppress this printed output?

Three archived responses worth possible review:
http://archive.midrange.com/midrange-l/200709/msg00249.html
http://archive.midrange.com/midrange-l/200709/msg00266.html
http://archive.midrange.com/midrange-l/200410/msg00596.html

The OUTPUT parameter specifies if invoked compilers will produce their listings. The OUTPUT() parm of RUNSQLSTM has its specified parameter value passed to the compiler(s) for any CREATE requests that are part of the script; i.e. OUTPUT(*NONE) on RUNSQLSTM might become OUTPUT(*NONE) on CRTSQLCI or OPTION(*NOLIST) on CRTxyz. See the command parameter help text [included here for reference]:

Listing output (OUTPUT)

Specifies whether the precompiler listing is generated.

Note: This parameter applies only to CREATE
statements for SQL procedures, functions, or
triggers in the source file. This value will be
used when creating the program for the SQL routine.

*NONE
The precompiler listing is not generated.

*PRINT
The precompiler listing is generated.

A similar feature to running a script of SQL statements, is the batch stream job [or any job really], where multiple statements [as /commands/ for CL]. The batch stream job has the logging controlled by a LOG() parameter. There is no [similar] LOG() parameter [nor OPTION() parameter as with various CRT* commands] for the Run SQL Statement command itself; there is no feature to control whether a log\listing will be generated, separate from the OUTPUT() parameter, which controls logging\listing only for the statements processed. There is no reason that a parameter [LOG() or OPTION()] should not exist to control the listing produced by RUNSQLSTM, so a design change request could be submitted, if such a function were desirable. Given the issue has come up several times just on these lists, might be evidence that the ability to suppress the statement logging of that SQL script processor might actually be somewhat worthwhile.

Regards, Chuck