Re: Packed and zoned decimal problem

Hi, Eric:

You might gain a small performance advantage on each I/O, but if you do much arithmetic with any zoned fields, your performance will suffer because the compiled code must convert zoned to packed internally to do any arithmetic, and then covert back to zoned again when storing the results into your zoned fields. If you do this in a loop, for example, the added overhead to convert back and forth between packed and zoned will start to dominate the total CPU consumed.

By design, RPG is a "scatter/gather" language. On input, it copies (or "scatters") all fields from the record buffer into equivalent working storage fields, and converts all zoned fields into packed working storage fields at that time. That way, all calculations (math, etc.) can proceed at full speed, as the working storage fields are already in packed format. Then, only when you WRITE or UPDATE the record, the fields are "gathered" from working storage back into the record buffer, and any packed working storage fields are converted back to zoned where needed, and the record is written out.

This is one reason why, in many cases, if you re-wrote a program line-for-line from ILE RPG IV into ILE COBOL or ILE C, if the program does a fair amount of calculations with any of the zoned fields, the RPG version will usually outperform the COBOL or C version by a wide margin. (This was also true for OPM RPG/400 vs. OPM COBOL or OPM PL/I, etc.)

Hope that helps.

Mark S. Waterbury

> DeLong, Eric wrote:

This is one good reason to use file I/O with Qualified Data structures,
IMO. When you declare an external DS, all field types are retained from
your reference file. No DB field mapping needs to occur, theoretically
making your app a little more efficient.

Eric DeLong
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Douglas Handy
Sent: Wednesday, October 22, 2008 6:06 AM
To: RPG programming on the AS400 / iSeries
Subject: Re: Packed and zoned decimal problem

David,

Could someone explain the last definition? If I were to pass myzone by

reference to a procedure, it's the packed version that gets passed. How should I pass this zone?

The definition of a field in an externally described file is its format
in that file. If the field is not also named in a data structure or
stand-alone D spec, then the compiler may use a different format for the
field. In general, both packed and zones fields will be stored
internally as packed. One reason it does this is, at least on the CISC
boxes, I believe performance of the arithmetic operations was better
when both operands were packed. But aside from performance, consider
what happens when the same field name exists in multiple files used by a
program. As long as the number of digits and decimal positions is the
same in each file, you can do that even when some files declare it as
zoned and others as packed. The reason that works is the field is moved
from its external definition to the program variable assigned to hold
that value, and that program variable is packed.

In order to force a program variable to be a particular format, name it
on a D spec and signify the type, or include the variable in a data
structure.
An easy way to do the later is to use an externally described DS based
on the file you are using. This forces each of the fields in the
program to use the same format as the external definition. Note however
that if multiple files have the same field name, you can't have that
name appear in multiple data structures because the program variable
must exist in only one memory location.

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