Re: CL program calling a command that doesn't exist on the compilation box

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.

Regards, Chuck