× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Well, there are a couple things going on.

1. On a command line (not in SQL) a number, by default, is packed (15,5) - packed is called "decimal" in SQL

2. I don't know that parameters are cast to what is needed - for example, if you pass a character literal, I believe it is passed as a VARCHAR, which often results in problems of not finding the right SP signature.

3. I'm not sure why the example with 14 digits worked - well, I think I do, because of the way packed values are handled - 14,5 and 15,5 both take the same number of bytes - all packed have a "sign" in the last nybble, so a 14-digit number takes 15 nybbles - well, you need another to make an even number of nybbles, that will be a 0, so it is the same as 15,5

4. Finally, you don't have to pass the length parameter - there is another stored procedure - you can find info at this URL -

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/IBM%20i%20Technology%20Updates/page/QSYS2.QCMDEXC%28%29%20procedure%20no%20longer%20requires%20a%20command%20length

so change your call to this - call qsys2.qcmdexc('wrkactjob') and Bob's your uncle.

Cheers
Vern

PS BTW, you CAN specify the number in its hex value, as here -

call qcmdexc('wrkactjob', x'000000000900000F')

On 11/23/2015 9: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?

Thanks,

Justin


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.