Re: Why isn't CALL QSYS.QCMDEXC('WRKACTJOB', 9.0); working but CALL QSYS.QCMDEXC('WRKACTJOB', 000000009.00000); is?

On 11/23/2015 10:09 PM, Justin Dearing wrote:

So from what I read QCMDEXEC takes two parameters, a command string, and a
length. I don't particularly want to call WRKACTJOB, but it was just a
simple example that would work on any given system. Anyway in this
particular case the command fails unless the 9 is preceded by 8 zeros and
suceeded by 5, which I guess explicitly forces the decimal to be (14,5).

Now the second parameter is a decimal(15,5), and the way I understand
stored proc parameters, either the value gets cast to the type the stored
proc wants, or it doesn't. On top of that, a string length has to be a real
number. Characters are atomic in SQL (and everywhere that isn't bizaro
land). So why is the parameter not an int or bigint, and why must it even
be specified?

The answer is weirder than you may like.

The qualified CALL, ie CALL QSYS.QCMDEXC is calling /the actual program/
which resides in the library QSYS. That program insists on having a
packed(15, 5) number. SQL has its own rules on how to store a literal,
which is why we need to specify all those extra zeroes - so that SQL
will pass a decimal(15, 5) to the program you are calling.

There is also a stored procedure, not coincidentally named QCMDEXC which
resides in QSYS2. If one were to call that stored procedure, one
wouldn't have to fiddle with the literals, because SQL wouldn't be
passing the literal to another program; it would be consumed by SQL itself.

So, a better approach would be to avoid the program and call the stored
procedure. All of these work in STRSQL on 7.2:

call qcmdexc('dsplibl output(*print)',22)
call qcmdexc('dsplibl output(*print)',22.0)
call qcmdexc('dsplibl output(*print)')
call qsys2.qcmdexc('dsplibl output(*print)')
call qsys2.qcmdexc('dsplibl output(*print)', 22)
call qsys2.qcmdexc('dsplibl output(*print)', 22.0)