Re: Packed vs. Signed db fields

>
> They are about to implement "standards" which say to make ALL numeric fields
> in the db zoned fields.  The argument being for the "chance" that they MAY
> at some time in the future have to interface with a PC package which MAY use
> FTP to download AS400 files.
>

I sure hope they're making the same concessions on the PC.   i.e. storing
everything in a format, such as XML, that can be FTPed and read by iSeries
programs.

If they're using software like Word, Excel, etc, other than the absolute
newest versions of these, the data is unreadable by the iSeries, and
therefore violates their rules.

Granted, these things can be exported to other formats -- but likewise,
your DB2 databases with packed numbers could be exported to other formats
(CPYTOIMPF is there explictly for this purpose)

Unless the iSeries is being treated as a 2nd-class machine, this rule
should be enforced both ways.

Not only THAT, but zoned decimal is not directly exportable to the PC
unless it contains a positive number.  Negative numbers will STILL be a
problem.


> I'm arguing that signed numeric is not really "native" to the AS400
> architecure, wastes disk space, and is a performance issue.  This one small
> issue is a problem for me, since it is "just not right" and I have problems
> with doing things that I feel are just wrong.  Expressing a (hopefully)
> educated opinion is part of being a consultant, I feel.
>

It's called "zoned" not "signed numeric".   Packed, Zoned, Integer all
support being signed.


> The slight cumulative performance gain is enough for me, having worked on
> over-taxed AS400s before where a nanosecond gained was a nanosecond gained.
> They are saying that "disk is cheap" and that we have plenty of disk and
> performance now.  I'd like to win this argument, since it just ain't right,
> particularly for a "standard".

I agree that this "just doensn't seem right".   But, I don't think you'll
ever notice the performance difference, or disk space...   we're not
talking about much here.   Even on a billion records, a nanosecond per
record difference isn't going to affect the bottom line.   And disk
space...   Wow.   Using packed instead of zoned isn't going to make much
difference here.  If disk space is truly an issue, you'd be better off
using some sort of zipping/compression software for uncommonly used
objects.   I can almost guarantee that there are 10 things wasting more
space than the packed vs. zoned issues.

>
> Does anyone have a convincing argument for this "small" issue, or any kind
> of stats on the performance just thrown out the window?
>

Decide on what's important to the company.

If interoperability between PC/OS400 is of top importance, then you
need to make sure that all of the PCs follow suit as well.   I'd also
store all numerics in alphanumeric fields, using edit codes so that
the negative numbers are represented in a PC-friendly manner.   Yes, this
will hurt performance, but if interoperability takes priority, then that's
what you do...

if you don't mind exporting things before having the interoperability,
then you can concentrate on performance.   Packed performs slightly better
than zoned.  (and much better than parsing a character string!!)
In this case, you can export the files when you need them.   Likewise, you
can export them on the PC.  Problem solved.