On Tue04-Apr-2011 08:36 , James Lampert wrote:
I'm working on a CL program that I'd like to compile on our
V4R4 box, that is to include a command (RUNSQLSTM) that exists
at that level of the OS, but not on that particular box.
Obviously, I could do it with QCMDEXC, or I could somehow get a
V4R4 RUNSQLSTM *CMD object onto the box (sans CPP, since the
command wouldn't have to execute thereon), but is there another
way I don't know about?
Since each command issued is actually a "statement" of the Command
Language Program source, there is no means to bypass the error other
than what is alluded; either to get\create a copy of the command to
support the specified parameters or to build the command string in the
program and pass that to the command processor via QCMDEXC or QCAPCMD.
Since the system on which the program runs might also be missing that
RUNSQLSTM command [for still being part of the ST1 versus the OS SS1],
an alternate means to perform the SQL script might be something to
consider. If the SQL script being run [and provided?] performs as
expected when run under the DB2 command line, then using QSH to invoke
the DB2 might be an option, reading as input the same source member that
the RUNSQLSTM would. Also since a source member is apparently part of
the mix, another source member which is a REXX SQL could either process
the script or just replace the scripted SQL statements to be run
directly with STRREXPRC which is part of the OS SS1 versus an LPP like
ST1. And from CLP there is [what is sometimes considered the even
better option is to have] a single-statement processor [I recall some
being called RUNSQL, however that moniker was also used for the iNav
feature] for which enabling MONMSG gives better logic control; a RUNSQL
implemented as a QMQRY using variables and then issuing the STRQMQRY
typically would be considered distasteful due to line length\wrapping
and quoting issues as I recall.