Re: Philosophical question...define table to be load from external data with integer or decimal fields...

Because different system use different endian schemes for multi byte
integers they are not really that portable. Since the data is probably
arriving as zoned then keep it that way. The relative efficiencies of the
different numeric schemes only matter if you are doing math on the value. I
there is no math involved then zoned is a simple byte move and as efficient
as anything else. Of course if the value arrives as an int and there is no
issue with big/little endian issues then keep it as an int.


On 2014-01-22, at 2:31 PM, Charles Wilt <charles.wilt@xxxxxxxxx> wrote:

David,

As I mentioned, the data is coming into the i, not going out; so the i is
the consumer. In any event, wouldn't some sort of integer be the most
portable?

Charles


On Wed, Jan 22, 2014 at 1:55 PM, David Gibbs <david@xxxxxxxxxxxx> wrote:

On 1/22/2014 12:51 PM, Charles Wilt wrote:

I'm creating a new table to hold data received from an external
source.

So MyField is a 5 digit number...

I could defined this as Packed/Zoned 5,0 Or I could use integer (or
even small integer since the current number of values is less than
1000)

Since I know DB2 and RPG for that matter perform best with integer,
I'm leaning that direction. But I can't help but think that Packed
(5,0) is more correct.

I use this technique extensively to send data back & forth between RPG
code and Java code.

For maximum flexibility, I suggests using zoned. This way your consumer
can handle the data regardless of the language or environment.

IMO, performance shouldn't be a serious concern. The few extra
microseconds you might get from using integer or packed shouldn't make a
difference. If it does, you've got bigger problems.

david


--
IBM i on Power Systems: For when you can't afford to be out of business!

I'm riding a metric century (100 km / 62 miles) in the 2014 Chicagoland
Tour de Cure to raise money for diabetes research, education, and

advocacy.

Sponsor me by visiting http://archive.ridewithdavid.com. Any amount is
appreciated.
--
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




--
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.