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



That's all well and good - but this is defined as 4 bytes, say, and has 0 decimals and nothing in the data type column - that is a 4-digit zoned field, right? The outline in 9.1 reports it to be a 7,0 packed - that can't be right.

On 10/24/2014 1:30 PM, Jon Paris wrote:
RPG will always convert zoned fields to packed for internal use - unless - the field in question is defined in a DS. Thus has ever been - at least on the S/38 side of the family.

So what Vern saw in RDi was accurate.

To see the difference just define a zoned file field in a DS (just bu specifying the filed name in the DS) and then hover over the variable and it will be shown as zoned.

A similar thing happens with date/time fields. No matter what format they have on the DB they will be converted by RPG to the default format for the program (normally *ISO) for internal usage. Same rule re placing the field in a DS applies here. The DS will preserve the original format. This is often a cause of performance issues with date heavy files where in DB2 they are in *USA but there was no *USA datefmt specified to the RPG program.

Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Oct 24, 2014, at 1:23 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:

On 24-Oct-2014 11:29 -0500, Vernon Hamberg wrote:
I just noticed, working in some old code, that when there is an
I-spec that defines a zoned field (blank in the data type and a
number in decimal places) that the field list displays it as packed.
<<SNIP>>
As I recall, that is the expected effect; an /implicit/ conversion to packed that consistently confounded me every time I looked at a listing and saw the Packed designation.

In my experience, as I recall, although the /field/ is being properly represented as zoned data for the actual file I\O, the /variable/ that gets declared to store that data is generated as Packed; i.e. in the expansion of the program listing where the data types\attributes are presented for the variables of the RPG program, a /variable name/ that happens to have been declared with the same name as the /field name/ appears as a Packed Decimal, but the I/O performs as expected because the /field/ within the database buffer is properly represented as Zoned Decimal.?

--
Regards, Chuck
--
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: 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.



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.