Re: Odd/Even packed numbers.

As far as I know, the way packed fields are stored has not changed--
you always have room for an ODD number of digits in a packed field.
Defining an EVEN number of digits 'wastes' 1/2 byte per field per
record.

Therefore, from a disk storage point of view, it's better to define
all packed numeric fields as ODD (9.0) rather than EVEN (8.0 for
example).  "Better" meaning that since OS/400 is going to allocate
the extra half byte anyway, why not define it?  In most shops someone
will want to use that extra digit at some point anyway.  Defining the
field with the extra digit avoids the need to redefine and recompile
your DDS and recompile all of your programs.

As far as occupying space on screen or paper-- in most cases, you
should use a field with a different name on the screen or page, so
it's not usually a problem.  Using the same name for the file and the
screen and the page is not usually a good idea-- it's too easy to
read in a disk record, pop up a maintenance screen, and accidentally
change more than you intended to.  I remember the days when "CUSTNO"
was the field name used in the customer master file, the screen file,
the open order file, and the order history file-- and the merry
mixups that resulted when an accidental Field Exit ended up writing a
new customer record with 00000 as the customer number...  and updated
the open order file, etc.  The fun continued when the 'bad' customer
master record was deleted, causing orders to go astray, or if another
accidental Field Exit wrote -different- customer master info under
key 00000. Yes, it's poor design, but I've seen it happen.

Better to read a disk record, move or z-add the data to the screen
field, and go from there.  Yes, it means you have to do some checking
to make sure the disk file doesn't overflow the screen field.  But it
means you can cram more on the screen, while your database is ready
for the new 200 x 50 screens.  (:

--Paul E Musselman
PaulMmn@ix.netcom.nospam.com

In the past (at S/38 times) we have been told that odd packed numbers were
not so efficient as even ones, and that - at design time - it was better to
define even packed numbers (for example 9.0 instead of 8.0).

The simple anwser could be to use 9.0 because it occupies the same storage
as 8.0, but unfotunately it occupies also one more byte in reports, panels,
etc. and - with other values - another byte for one more decimal separator.

Is there any evidence that with RISC processors this is still true?
If so, how much system performances could degrade in case of large files?

-- Giuseppe