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

If a numeric parameter is received from the command line the system _has_ to make some assumption as to its format before passing it to the program or whatever. Remember the program only receives a pointer to the value - the program itself has to know exactly what format of data is expected to be referenced by that pointer. For whatever reason the decision was taken that it be a 15,5 packed. If I recall correctly this goes all the way back to the S/38.

It would really make no sense to have it assume integer if there was no decimal place - you’d then have to be certain to key in a decimal point when entering a value like 15.0 - as just 15 would be interpreted incorrectly.

Character fields result in character variables of 32 long (or however long it actually is if longer than 32), numerics result in a numeric and 15,5 is about as good a compromise as one could reasonably expect.

On Nov 24, 2015, at 7:29 AM, rob@xxxxxxxxx wrote:

IDK the total history behind 15,5. I agree it makes no sense and how can
a command string have a decimal value. Nearest I can figure 15,5 was as
large as numbers were allowed in the wayback machine. I don't happen to
have a V1R2 RPG Reference around here to check.
Integer was a relatively new comer. Binary was an earlier forerunner but
that unfortunate name strikes fear into some. That, and the conversion
involved.


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: Justin Dearing <zippy1981@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 11/23/2015 10:10 PM
Subject: Why isn't CALL QSYS.QCMDEXC('WRKACTJOB', 9.0); working but
CALL QSYS.QCMDEXC('WRKACTJOB', 000000009.00000); is?
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



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
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

Jon Paris

www.partner400.com
www.SystemiDeveloper.com