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



My understanding is that all decimal math is done in software which is why
they say always use integer where possible because it does math in hardware
and my understanding is that it always does math in packed decimal which
makes sense to me. Why have two decimal math packages, one for zoned and
one for decimal?

But, of course, maybe I am wrong.

On Mon, Mar 26, 2018 at 9:20 AM, Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote:

"Zoned decimal must be always converted to packed before any math is done
on it and then converted back to zoned."

You sure that is still true Alan? Back in the S/38 and early AS/400 days
there was hardware support for packed operations - but I don't think that
is true of the Risk machines. Larry, Jim or Mark (among others) might know.

For sure if you take no steps to prevent it then RPG will always convert
external fields in zoned format to packed and that gives the impression
that packed is the preferred format, but that is a historical artifact -
just as S/36 apps used zoned as the default.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Mar 26, 2018, at 12:12 PM, Alan Campin <alan0307d@xxxxxxxxx> wrote:

If no decimal point, then always integer.type. If decimal point, should
always be packed odd if possible.

Zoned decimal must be always converted to packed before any math is done
on
it and then converted back to zoned.

Why would you do that?

On Mon, Mar 26, 2018 at 8:51 AM, Craig Richards <craig@xxxxxxxxxxxxxxxx>
wrote:

I've never been able to buy that argument.

The primary purpose of the database is to store/retrieve your data
efficiently.
Appeasing people who want to use DSPPFM shouldn't be a design
consideration.

There are lots of tools and presentation layers to let them see that
data
however they like.

Are you going to disallow the use of XML, CLOB, BLOB types because they
can't be viewed with DSPPFM?

For normal numeric data - my vote is odd packed every time ( why waste a
nibble? And anyway I worry about the stray nibble )

I have used integer types for auto-gen ID columns and to keep those
JDBC-accessing java types happy, but it sits uneasily with me...

That said, I recognise I seem to be in a minority.

/cough and not just in this regard
/sigh

Craig

On 26 March 2018 at 16:32, Justin Taylor <JUSTIN@xxxxxxxxxxxxx> wrote:

The other devs here still have a death-grip on DSPPFM, so data that's
not
human-readable is always a fight. They've acquiesced for integer data,
but
for other numerics I have to stick with human-readable (ie. avoid
packed).

I'm not sure it makes a huge difference to the OS, unless you're trying
to
wring the absolute most performance possible.



-----Original Message-----
From: Jay Vaughn [mailto:jeffersonvaughn@xxxxxxxxx]
Sent: Monday, March 26, 2018 9:46 AM
To: RPG programming on the IBM i (AS/400 and iSeries) <
rpg400-l@xxxxxxxxxxxx>
Subject: new table development (decimal vs numeric)

In a 60/40 (RPG to Cobol) shop, with no new cobol development...

Aside from special cases where integer and float may be needed...

For common "numeric" data, what is the best standard data type
definition,
if choosing from decimal or numeric?

I do know decimal is packed and I have an "impression" that rpg is most
compatible with packed and will convert to packed under the covers when
needed. Not sure what I REALLY mean except that I would lean towards
decimal being the best standard choice in an RPG shop.

What do you think?

--
This is the RPG programming on the IBM i (AS/400 and iSeries)
(RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD


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.