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

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

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.

As an Amazon Associate we earn from qualifying purchases.

This thread ...


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

This mailing list archive is Copyright 1997-2021 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.