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

On Mon, Nov 23, 2015 at 11:05 PM Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
wrote:

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.

Ok coming from RDBMSes where you dont have signature overloads, I could see
why casting doesn't always work. The system doesn't have one set of holes
to jam the data into.

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

Ok now having a better idea of ho DB2 for I works from the preceding
paragraphs that makes sense.

4. Finally, you don't have to pass the length parameter<snip/>
so change your call to this - call qsys2.qcmdexc('wrkactjob') and Bob's
your uncle.

Ok that's so much easier. So whats the historical reason for having to
specify the length?

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

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

I've actually used the reverse of that parlor trick on IEEE floats for
education purposes. An analyst doing real statistics was doing
float1=float2 in a WHERE clause and not getting what he wanted. So I casted
them to hex to show how off the numbers were, then said "google IEEE FLOAT"
and suggested he change his where clause to ABS(FLOAT1-FLOAT2) < 0.001 or
some other tolerance. Sometimes you gotta show people the hex values so
they will open their mind and grok the FLOAT/DECIMAL difference.